'Twas brillig, and Josh Triplett at 22/04/13 22:53 did gyre and gimble: > 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. > 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.
>From what I gather what you're trying to solve here is a packaging problem - i.e. that multiple packages may have a requirement for a given user to exist and that if said packages are removed, the user should disappear again? If that is the case, then shouldn't the code actually be part of a packaging helper script rather than managed by a daemon? Also, if there is a .d folder setup here who owns those files? e.g. if I have postfix and cyrus-imapd packages, both will want the "mail" user. In that case who owns the /usr/lib/passwd.d/news file? They kinda both do need to provide that file, but that's wrong in and off itself - you'd be better creating a structure for this. Also the "nothing uses the UID or GID anymore" test is a bit hard is it not? I mean we'd have to check all file ownership and ACL entries on all mounted filesystems would we not? Sounds like a bad idea to me. All in all I still thing this is better handled by packaging helper scripts. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
