8622 2015-11-02 08:28:29 +0000 e2fsprogs: support xattr 2016-01-19 10:32:23 +0000 1 1 7 Build System, Metadata & Runtime OE-Core devtools / tool chain 2.1 x86 Multiple RESOLVED FIXED Medium enhancement 2.1 M2 1 patrick.ohly liezhi.yang bluelightning joshuagloe meta.mr.watcher meta.watcher richard.purdie --- --- No (bug/feature does not impact docs) oldest_to_newest 56069 0 patrick.ohly 2015-11-02 08:28:29 +0000 Current master branch of e2fsprogs contains support for creating images with xattrs. Updating to that code would allow different layers which currently carry their own patches for that (meta-intel-iot-security, meta-selinux) to remove their patches and use a common, upstream code base again. It would also fix certain file system corruption problems that we've seen with meta-intel-iot-security, but could never fully reproduce in OE-core itself (only one part of those were fixed in bug #8544 by backporting from master). 56231 1 richard.purdie 2015-11-05 15:45:08 +0000 As I understand it, we have patches in Yocto jethro/master which supports xattrs. If we don't, we should look into how we can get that support, perhaps on the latest stable 1.42 release. I'm hearing rumour that 1.43-pre hasn't been released as there are stability concerns with it and as such I'm worried that switching to such a pre release may cause more problems that it solves. Do we have a known good version of e2fsprogs that works ok without corruption with xattrs? Really need more info since blindly updating to 1.43-pre worries me. 56245 2 patrick.ohly 2015-11-05 17:02:03 +0000 If I remember correctly, Robert said that 1.42 does not yet have the "create image from directory" support. 1.43-pre would have that plus xattr and thus can be used directly with no or only very minimal build patches. I can try 1.42 plus separate "create image from directory" patch if someone prepares it. 56255 3 liezhi.yang 2015-11-06 03:06:16 +0000 (In reply to comment #2) > If I remember correctly, Robert said that 1.42 does not yet have the "create > image from directory" support. 1.43-pre would have that plus xattr and thus I had ported the patches "create image from directory" to 1.42. > can be used directly with no or only very minimal build patches. > > I can try 1.42 plus separate "create image from directory" patch if someone > prepares it. It is already in oe-core's 1.42 e2fsprogs. 56260 4 patrick.ohly 2015-11-06 08:33:13 +0000 Sorry, I had lost track of what is in OE-core and what isn't. While moving to 1.43-pre would allow OE-core to drop some patches because creation from a directory is in that upstream version, the real motivation for filing this issue was the lack of xattr support in current OE-core. I've renamed the issue accordingly. Instead of moving to 1.43-pre, another solution would be to take in the patches that are currently in meta-selinux. Besides the e2fsprogs_1.42.bbappend and its patches, the linux-libc-headers%.bbappend change is also needed. I tried that and can confirm that it also fixes the problem that we have with the current xattr patches in meta-intel-iot-security. 56499 5 sjolley.yp.pm 2015-11-16 20:59:50 +0000 It appears the questions have been answered. If other items require NEEDINFO, please place it back in that state. 57140 6 patrick.ohly 2015-12-09 10:36:53 +0000 Do we have an estimate when this might get done? 57147 7 patrick.ohly 2015-12-09 16:31:20 +0000 When you add it to OE-core, can bump the version that is higher than 1.42.9 (the current version in OE-core) and (more importantly) higher than 1.42.9+git... (which is what we had in meta-intel-iot-security)? Something like 1.4.9+1 perhaps? 57156 8 patrick.ohly 2015-12-10 11:36:56 +0000 Choosing a suitable candidate that meets the requirement won't be as easy as I thought. I noticed that the e2fsprogs from meta-selinux also has problems. My testcase is a build with meta-security-smack and meta-integrity enabled and capabilities set for one binary, leading to: $ bitbake -c devshell iot-os-image # getfattr -d -m . ../rootfs/etc/ # file: ../rootfs/etc/ security.SMACK64="System::Shared" security.SMACK64TRANSMUTE="TRUE" # filecap `pwd`/../rootfs/bin/busybox.net_raw file capabilities .../rootfs/bin/busybox.net_raw net_raw # getfattr -d -m . ../rootfs/bin/busybox.net_raw # file: ../rootfs/bin/busybox.net_raw security.capability=0sAQAAAgAgAAAAAAAAAAAAAAAAAAA= security.ima=0sAwIC2C1O/QCAhDxwbreBIrADq3f0LdBQ3D2LAF/KE2IhFSnAI9kz8anW0+MzC7aSMR+MSi6DJ0NlDBmHthjG9m6hWxHWFHhlDMZegkBBxow4LdM5Ia/puQHYGwWjWc1tqi+awU2HjlsnsE3Y+QEn8dUCYFOSeFgftZxDtAX6jMDk/2vvYtlnrjU= With e2fsprogs from meta-selinux I only get into the ext4 partition: # getfattr -d -m . /etc getfattr: Removing leading '/' from absolute path names # file: etc security.SMACK64="_" security.SMACK64TRANSMUTE="TRUE" root@qemux86:~# filecap /bin/busybox.net_raw root@qemux86:~# getfattr -d -m . /bin/busybox.net_raw getfattr: Removing leading '/' from absolute path names # file: bin/busybox.net_raw security.ima=0sAwIC2C1O/QCAhDxwbreBIrADq3f0LdBQ3D2LAF/KE2IhFSnAI9kz8anW0+MzC7aSMR+MSi6DJ0NlDBmHthjG9m6hWxHWFHhlDMZegkBBxow4LdM5Ia/puQHYGwWjWc1tqi+awU2HjlsnsE3Y+QEn8dUCYFOSeFgftZxDtAX6jMDk/2vvYtlnrjU= Note that security.SMACK64 has the wrong value. With e2fprogs 1.43-pre, the result is slightly better, but security.capabilities still gets dropped: # getfattr -d -m . /etc/ getfattr: Removing leading '/' from absolute path names # file: etc/ security.SMACK64="System::Shared" security.SMACK64TRANSMUTE="TRUE" root@qemux86:~# filecap /bin/busybox.net_raw root@qemux86:~# getfattr -d -m . /bin/busybox.net_raw getfattr: Removing leading '/' from absolute path names # file: bin/busybox.net_raw security.ima=0sAwIC2C1O/QCAhDxwbreBIrADq3f0LdBQ3D2LAF/KE2IhFSnAI9kz8anW0+MzC7aSMR+MSi6DJ0NlDBmHthjG9m6hWxHWFHhlDMZegkBBxow4LdM5Ia/puQHYGwWjWc1tqi+awU2HjlsnsE3Y+QEn8dUCYFOSeFgftZxDtAX6jMDk/2vvYtlnrjU= 57157 9 patrick.ohly 2015-12-10 11:46:19 +0000 The revision of 1.43-pre was 0f26747167cc9d82df849b0aad387bf824f04544 The recipes I used are here: https://github.com/pohly/meta-intel-iot-security/tree/e2fsprogs-1.43-pre https://github.com/pohly/meta-intel-iot-security/tree/e2fsprogs-selinux 57201 10 patrick.ohly 2015-12-11 13:22:56 +0000 The reason why security.capability of busybox.net_raw does not get copied into the image is due to a flaw in the input data, not because of a flaw in e2fsprogs: busybox.net_raw is a hard link to busybox.suid. pseudo allows setting capabilities and the suid bit differently for them (that's why everything looks alright in "-c devshell", but in a real file system that is not possible, because file attributes are attached to the inode, not the directory entry. e2fsprogs thus randomly copies the attribute from one of the copies. However, the meta-selinux problem with not coping security.SMACK64="System::Shared" on /etc seems to be real. 57948 11 liezhi.yang 2016-01-19 10:32:23 +0000 Updated to 1.43 WIP: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=8c3276ecea38d4d67c22e6db49060b2d4b457278