On Sun Sep 01 04:47 PM, Max Rees wrote:
As of this writing, there appears to be:
* 24 packages that use the $pkgusers and $pkggroups directives.
* 3 packages that only use the $pkggroups directive.
* 0 packages that only use the $pkgusers directive.
* 12 packages that use chown(1) or chgrp(1) in the APKBUILD, 8 of which
are not included in any of the above.
And an unknown amount of packages that perform their own chown or chgrp
during the vendor's installation process (this may later be estimated by
examining all available apks and checking for user, group != root).
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
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
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
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
* it makes it easier to audit changes to these file attributes during
* 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
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.