[systemd-devel] "dynamic" uid allocation (was: [PATCH] loopback setup in unprivileged containers)

[Josh Triplett]

Lennart Poettering wrote:
> Hmm, so, I thought a lot about this in the past weeks. I think the way
> I'd really like to see this work in the end is that we never have to
> persist the UID mappings. This could work if the kernel would provide
> us with the ability to bind mount a file system into the container
> applying a fixed UID shift. That way, the shifted UIDs would never hit
> the actual disk, and hence we wouldn't have to persist their mappings.

It ought to be possible to run an arbitrary distribution inside a
container, even a distribution that itself wants to run sandboxed
applications in containers.  Nesting matters, so a bare shift may not
suffice.  On the other hand, a shift is the simplest solution for simple
utility containers, such as those launched by systemd-nspawn.  nspawn
could trivially avoid persisting the UID map by applying a shift, while
a full container solution might want to construct persistent dynamic UID
maps, or integrate with special PAM/NSS modules, or any number of other
creative solutions.

Container UID handling was exactly what I had in mind when I sent in a
kernel patch for the setusers() system call.  If an unprivileged user on
the host system can have a pile of UIDs handed to them by the host
system, and can use any of those IDs in their UID map, then they can set
up any arbitrary container UID handling without further assistance from
host root.  A PAM module on the host could then, by policy, hand some or
all unprivileged users a substantial stack of host UIDs that they can
arbitrarily map to container UIDs; together with support for applying
UID maps to a mounted filesystem, that would provide all the necessary
kernel support.

In addition to containers, that would also provide a sensible solution
for a smarter fakeroot-style tool that lets a user construct filesystems
with slightly more complicated policies than "root owns everything",
again without any help from host root other than "here, have a pile of
subordinate UIDs".

I'd be happy to revisit kernel setusers() support if anyone would be
interested in saying "yes, this is the solution we want".

- Josh Triplett