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

[Alexey Shabalin]

2013/4/23 Josh Triplett <josh at joshtriplett.org>

> 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.
>

:)
realy need new bike?
please see  http://www.openwall.com/tcb/
This alternative to /etc/shadow in ALTLinux sinse 2000.


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



-- 
Alexey Shabalin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20130423/db6d5b85/attachment.html>