[adelie-devel] Re: [RFC] Technical proposal for fakeroot removal

On Sun Sep 01 04:47 PM, Max Rees wrote: When I was originally investigating this I hit a blocking problem I described on IRC and forgot to mention here: Linux file extended attributes (xattrs), which abuild and apk already currently support. In particular, Linux file capabilities are implemented as xattrs under the the "security.capability" name: $ getfattr -d -m - /usr/bin/ping # file: usr/bin/ping security.capability=0sAAAAAgAgAAAAAAAAAAAAAAAAAAA= As it stands now, xattrs are handled opaquely by fakeroot. Our abuild creates the data.tar.gz file using the PAX format via libarchive's bsdtar (Alpine uses GNU tar and only recently switched to the PAX format in order to facilitate reproducible builds, which is something I'm also interested in). libarchive then stores xattrs as PAX extended attributes under the names "LIBARCHIVE.xattr" and "SCHILY.xattr" using two different encoding schemes for the xattr name and value. SCHILY.xattr is also supported by Jörg Schilling's "star" (hence SCHILY) and GNU tar, both with yet more different encoding schemes for the xattr name. However, for the vastly more common case of pure ASCII xattr names these formats are all interchangeable; and all implementations of SCHILY.xattr insert the xattr value as raw bytes (if the xattr value contains a newline this could be a conflict with the PAX extended attribute format...) The problem: libarchive's mtree does not currently support xattrs in any way. Indeed, I don't think FreeBSD nor NetBSD's mtree utilities do either. The only prior art I could find was "go-mtree" by Vincent Batts, which adds parsing for mtree keywords of the form: xattr.<octal escaped name>=<base64 encoded value> This week I began implementing support for this format in libarchive's mtree plugins. I am still waiting to hear back on what its maintainers think of this proposal before I continue working on it. If I can move forward with this implementation, then I can also move forward (post-1.0) on replacing fakeroot completely with mtree declarations. In addition to getting rid of the ugly hack fakeroot imposes, this has some other nice properties: * it is always clear from the APKBUILD where certain files deviate from the standard root/root ownership, or when file capabilities are present. * it makes it easier to audit changes to these file attributes during package upgrades. Side notes: * It gets even more complicated when user namespaces are introduced. When a file capability is written by a user with sufficient permission inside a user namespace, the kernel actually translates it so that the capability also records information about the namespace (i.e. what UID maps to UID zero if I recall correctly): $ getfattr -d -m - ~/adelie-master-x86_64.chroot/usr/bin/ping # file: adelie-master-x86_64.chroot/usr/bin/ping security.capability=0sAAAAAwAgAAAAAAAAAAAAAAAAAACghgEA This is of course to prevent trivial privilege escalation: $ ~/adelie-master-x86_64.chroot/usr/bin/ping example.com ping: socket: Operation not permitted However, currently fakeroot intercepts the xattr creation calls before they ever reach the kernel, so in the data.tar.gz file the capabilities are stored with no container restrictions. This also will not be a problem when using mtrees; it's just an interesting facet I wanted to share from my research. * I'm also interested in trying to eliminate most of the setuid/gid binaries in Adélie using file capabilities. As far as I know only iputils currently uses them. * At some point I will probably adjust my much-revised checkapk script to switch to the mtree format in its output to facilitate this process. Max