[systemd-devel] [PATCH] TODO: passwd.d, group.d

[Josh Triplett]

On Thu, Apr 18, 2013 at 12:26:15AM +0200, Kay Sievers wrote:
> On Wed, Apr 17, 2013 at 11:50 PM, Josh Triplett <josh at 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