On Thu, Apr 18, 2013 at 12:26:15AM +0200, Kay Sievers wrote: > On Wed, Apr 17, 2013 at 11:50 PM, Josh Triplett <j...@joshtriplett.org> wrote: > > --- > > TODO | 5 +++++ > > 1 file changed, 5 insertions(+) > > > > diff --git a/TODO b/TODO > > index eb482d0..6cf632a 100644 > > --- a/TODO > > +++ b/TODO > > @@ -679,6 +679,11 @@ External: > > - put bootcharts in the journal > > - kernel cmdline "bootchart" option for simplicity? > > > > +* Support passwd.d and group.d; accumulate a persistent name/number map, to > > + preserve UID/GID assignments without requiring assignment of unique IDs > > at > > + adduser time. > > Hmm, how is that related to systemd code? Sounds more like a glibc > shipped feature/plugin?
It would involve a PAM plugin as well, yes, but also a system daemon watching those directories for changes and allocating new systemwide UIDs and GIDs, and I also suspect several bits of systemd functionality would want to integrate with it, notably logind and container bits. > > Allows installing users without maintainer scripts, and makes > > + UID namespaces easier to manage. > > How would that happen? How do you pre-allocate the numbers in a tiny > 32bit number range. We do not have UUIDs for that like some "real" > operating systems have. :) It'd be nice to start looking into what it would take to support 64-bit UIDs and GIDs, but in the meantime 32 bits still seems like enough to allocate new system UIDs when files show up in one of the passwd.d directories, preserve their mapping, and garbage-collect them when no longer needed. That garbage-collection bit also seems like something systemd would need to help with. As for containers, it just means that users would get very few UIDs and GIDs to use in their containers. - Josh Triplett _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
