[OE-core] [PATCH] shadow: 'useradd' copies root's extended attributes

wenzong fan wenzong.fan at windriver.com
Thu Jan 4 09:28:27 UTC 2018


Hi José Bollo,

This will override the labels of user's home directories that set by 
SELinux.

For example, if I run below command on SELinux enabled system:

$ useradd test

SELinux will label it as "user_u:object_r:user_home_dir_t:SystemLow" 
first, and then useradd will reset the label as 
"system_u:object_r:etc_t:SystemLow".

I got strace logs below:

723   openat(AT_FDCWD, "/proc/thread-self/attr/fscreate", 
O_RDWR|O_CLOEXEC) = 11
723   write(11, "user_u:object_r:user_home_dir_t:"..., 35) = 35 

723   close(11)                         = 0
723   mkdir("/home/t1", 000)            = 0
723   chown("/home/t1", 1000, 1000)     = 0
723   chmod("/home/t1", 0755)           = 0

# SELinux labelled it as "user_home_dir_t" here.

723   llistxattr("/etc/skel", NULL, 0)  = 17
723   llistxattr("/etc/skel", "security.selinux\0", 17) = 17
723   openat(AT_FDCWD, "/etc/xattr.conf", O_RDONLY) = -1 ENOENT (No such 
file or directory)
723   lgetxattr("/etc/skel", "security.selinux", NULL, 0) = 27
723   lgetxattr("/etc/skel", "security.selinux", 
"system_u:object_r:etc_t:s0", 27) = 27
723   lsetxattr("/home/t1", "security.selinux", 
"system_u:object_r:etc_t:s0", 27, 0) = 0

# useradd reset the label as "etc_t" here.

Do you agree to move the patch to Smack specific layer? Such as 
meta-security?

Thanks
Wenzong

On 03/15/2017 04:04 PM, José Bollo wrote:
> On Thu, 09 Mar 2017 18:18:05 +0100
> Patrick Ohly <patrick.ohly at intel.com> wrote:
> 
>> On Thu, 2017-03-09 at 17:48 +0100, José Bollo wrote:
>>> On Thu, 09 Mar 2017 17:07:54 +0100
>>> Patrick Ohly <patrick.ohly at intel.com> wrote:
>>>> Can't you reorder and rebase the patches so that this
>>>> 0001-useradd.c-create-parent-directories-when-necessary.patch
>>>> applies on top of the patch which was submitted upstream?
>>>
>>> I agree that it would be better to reorder. Better but less
>>> conservative because an existing patch must be upgraded.
>>
>> If upstream merges the proposed patch, then rebasing will be
>> inevitable at some point, so we might as well do the cleaner solution
>> now, even if the diff becomes larger.
>>
>>>> "devtool modify shadow-native" might be useful for that. "git
>>>> rebase -i" in workspace/sources/shadow-native", then finish with
>>>> "devtool update-recipe shadow-native". I haven't tried whether
>>>> "update-recipe" handles re-ordering patches. If it doesn't, just
>>>> fix it manually.
>>>
>>> I'll do and propose the new version soon.
>>
>> Thanks!
>>
> 
> I pushed a new version of the patch this monday. I suppose that it is
> waiting for approval.
> 
> Best regards
> José Bollo
> 



More information about the Openembedded-core mailing list