2013/4/23 Josh Triplett <j...@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 <j...@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 < > 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. > > > > 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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- Alexey Shabalin
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
