On Thu, 4 Jan 2018 17:28:27 +0800 wenzong fan <wenzong....@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.o...@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.o...@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 > > -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core