Bug 8622

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.

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.

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

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.

It appears the questions have been answered.   If other items require NEEDINFO, please place it back in that state.

Do we have an estimate when this might get done?

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?

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=

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

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.

Updated to 1.43 WIP:

http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=8c3276ecea38d4d67c22e6db49060b2d4b457278