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

Josh Triplett josh at joshtriplett.org
Mon Apr 22 14:53:50 PDT 2013


On Mon, Apr 22, 2013 at 11:24:56PM +0200, Kay Sievers wrote:
> On Mon, Apr 22, 2013 at 9:29 PM, Josh Triplett <josh at joshtriplett.org> wrote:
> > 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.
> 
> Sorry, I lost you. I have really no idea what you are looking for.
> 
> Care to start at the beginning again, I read all that again but I
> don't get it. :)

1) Leave only root in /etc/passwd and /etc/group.
2) Add passwd.d and group.d directories in /etc and under /usr, which
   accept one record per file (with name given by the filename) and
   which do not include UIDs or GIDs.
3) When new users or groups show up, dynamically allocate new IDs for
   them, and record them in a separate persistent name<->number mapping
   used by the PAM module.  Keep them there as long as the .d file
   exists, or as long as anything on the system (file or process) uses
   the UID.
4) When the .d file goes away, and nothing uses the UID or GID anymore,
   throw it at the back of the list of IDs to reuse.
5) In the same daemon managing this, optionally support minting small
   numbers of ephemeral UIDs/GIDs for use in containers, when they don't
   need to map to any useful persistent privileges on the host system.
   Also optionally support creating new non-ephemeral UIDs/GIDs, for
   persistent use on the host.
6) Eventually move to a big enough ID space that reuse becomes
   irrelevant, and then allow users to obtain larger blocks of IDs for
   container use.

Effectively, treat ID numbers as magic rotating implementation details
that nobody should care about, and names as the primary identifier.

- Josh Triplett


More information about the systemd-devel mailing list