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

[José Bollo]

On Thu, 4 Jan 2018 17:28:27 +0800
wenzong fan <wenzong.fan at windriver.com> 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
> 
> 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?

I agree.

SELinux is the king of monsters and pushes others in corners...

Best regards
José

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