Re: [PATCH] shadow: 'useradd' copies root's extended attributes

[wenzong fan <wenzong.fan@windriver.com>]

On 01/04/2018 05:28 PM, wenzong fan wrote:
> 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
> 

Sorry for the typo: s/test/t1/g to match with strace logs.

// Wenzong

> 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@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@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
>>
>