fedora-atomic discussion point: /usr/lib/passwd
mzerqung at 0pointer.de
Fri Apr 11 16:39:26 UTC 2014
On Fri, 11.04.14 15:49, Colin Walters (walters at verbum.org) wrote:
> On Fri, Apr 11, 2014 at 10:34 AM, Lennart Poettering
> <mzerqung at 0pointer.de> wrote:
> >I am really not convinced that this is a good idea and will really
> >fly. Having a fully static passwd file can't really work since admins
> >must have the ability to change certain user attributes for certain
> >system users. This is quite obvious for the root user,
> root is in /etc/passwd. What this means in practice is that as soon
> as another user is added, the client machine has a forked copy of
> /etc/passwd, and will no longer receive any changes to root's entry
> either. But it's not like we change it much.
Would you copy the entire file from to /etc or just that one entry?
I can see why you would like to avoid the population step, but if we
want that, then let's go one step further: have a drop-in dir in /usr,
where packages can drop in new user definitions for system users, which
is then scanned by an NSS module. tools like "passwd" would then have
to be patched to be able to copy individual entries into /etc when they
shall be updated.
Now, this still leaves the question open what to do about system users
that do not have statically assigned numeric UIDs, in particular
everything 3rd party. If I understand you correctly, you want this to be
convered by systemd with a new service option that will allocate the uid
on first service start?
So how about this then, we have a drop-in dir in /usr as above, with
files that list the numeric UID where possible. For the cases where
that's not possible however, we'd check some additional db in /var. If
that db doesn't contain a numeric UID yet the lookup would fail. Then,
we'd add logic to systemd to possibly assign numeric UIDs to such users
when User= is specified for a service. In addition we'd add a new switch
AlocateUser= or so, which does the same thing for arbitrary users,
without implying the setresuid() bit that User= is for? Using
AllocateUser= would also imply RequiresMountsFor=/var/lib/userdb (for
the right path...).
Essentially this would mean we would allow dynamic UIDs only for
later-boot services (i.e. normal services), but not for early-boot
services, which sounds like a OK restriction to make to me.
With that in place the population of /etc/passwd would be unnecessary.
Did I get this right that this is would be inline with what you are
asking for? I am warming up to this.
Lennart Poettering, Red Hat
More information about the devel