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

[Lennart Poettering]

On Tue, 30.12.14 06:49, Simon Peeters (peeters.simon at gmail.com) wrote:

> 2014-12-29 14:14 GMT+00:00 Tom Gundersen <teg at jklm.no>:
> > On Mon, Dec 29, 2014 at 2:34 PM, Lennart Poettering
> > <lennart at poettering.net> wrote:
> <snip>
> >> I am open to adding support for this, but I think the allocation of
> >> the UID ranges should really happen automatically, and not be
> >> something the admin has to manually assign.
> >>
> >> Which means we'd enter dynamic UID allocation terroritory, and that
> >> opens a huge can of worms...
> >
> > Would we not also need to support explicit assignment, in case someone
> > has a preexisting image they want to match in a specific way? In that
> > case we could start off without the dynamic allocation and add that
> > later. It certainly would make testing a lot simpler if we had userns
> > support sooner rather than later (at least in the case of netlink it
> > appears to be quite a mess).
> 
> Inspired by this topic I wrote a quick'n'dirty uid allocator[1]
> this allocator manages the upper 2G uid's, which using Matthias Urlichs example
> of 2048 uid's per container, still allows for 1M containers.
> 
> It curently can't persist these allocations, but that is on my
> "0.0.1" todolist.

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.

Instead on each container startup we'd look for a new UID range, and
release it entirely when the container shuts down. The bind mount with
UID shift would then shift the UIDs up, the userns stuff would shift
it down from inside the container again.

Of course, this all depends on whether the kernel will get an
extension to apply uid shifts to bind mounts. I hear they want to
provide this, but let's see.

I kinda would prefer to see how that works out before we add any
infrastructure for automatic allocation to systemd, since only then we
have the full picture to consider.

Lennart

-- 
Lennart Poettering, Red Hat