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

From: Max Rees <maxcrees_at_me.com>
Date: Thu, 18 Jun 2020 18:27:33 -0500

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

  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.

Received on Thu Jun 18 2020 - 23:49:15 UTC

This archive was generated by hypermail 2.4.0 : Sat May 08 2021 - 22:54:40 UTC