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

[Colin Guthrie]

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

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