fedora-atomic discussion point: /usr/lib/passwd

[Simo Sorce]

On Fri, 2014-04-11 at 18:39 +0200, Lennart Poettering wrote:
> 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...).

This sounds extremely brittle, I can see people causing all sort of
issues releasing unit files that have AllocateUser by default.
Then when someone puts those users in a network database (ldap, nis,
etc), a conflict would be generated the first time the service is
started and the user is not found (because the server fell off the
network).

I think this scheme is baroque and prone to nasty failures in real
deployment. Please don't do that.

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

It is just a recipe for disaster, you are making the whole system
fragile in order to handle a corner case.

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

I think it is a *very* bad idea,

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York