2014-12-29 14:14 GMT+00:00 Tom Gundersen <t...@jklm.no>: > On Mon, Dec 29, 2014 at 2:34 PM, Lennart Poettering > <lenn...@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. You can request a uid range (or single uid) via dbus or using the command line: # uidalloc alloc 2048 allocates a chunk of 2048 uid's # uidalloc release ${id returned by above command} releases the chunk again. An allocated chunk can be accessed 2 ways: - using the id "generated" by uidallocd - using an alias passed by the client application The idea is that for example systemd-nspawn could use "sd_nspawn_${machine_id_of_container}" as an alias, so that when it starts the container it checks fot the existance of that alias, and if it doesn't exist it leases a new chunk. Also I have written this to be generic, so that (If anybod ever uses this) it could also be used for f.ex guest sessions, ldap users,... if anybody wants to help out: feel free to do so. if you are interested and have questions: shoot! Greetings Simon Peeters [1] https://github.com/SimonPe/uidallocd ps: I know the code is ugly, my terminology is wierd, and all other stuff. If that bothers you: fix it. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel