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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
