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

Simo Sorce simo at redhat.com
Fri Apr 11 17:14:15 UTC 2014


On Fri, 2014-04-11 at 19:01 +0200, Lennart Poettering wrote:
> On Fri, 11.04.14 12:47, Simo Sorce (simo at redhat.com) wrote:
> 
> > > 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).
> 
> This has come up before. But: system users must be resolvable locally,
> always, and unconditionally. udev, tmpfiles, ... will all break if that
> is not the case. 

This is true for *some* system users.

> if you place system users in LDAP, then it's your own fault if things
> break, and we should strictly not support that.

It is ok if my 'foo' database fails to start if the network is down.
It is *an entirely* different matter if the system creates a mismatching
(different uid/gid) user out of its ass when that happens.

> It's one thing to sync system users against LDAP, but storing them there
> exclusively cannot work, and is currently not supported, and is
> something we should not support.

We do not need to support it as in "we guarantee your application will
always work", but it is unreasonable to build a system where "we
guarantee to screw you up" if a lookup ever fails for whatever reason.

> > I think this scheme is baroque and prone to nasty failures in real
> > deployment. Please don't do that.
> 
> Nope. The baroque/error-prone bit is to place system users in LDAP,
> everything else is just a corrollary of that...

This scheme is not fail safe, hence it is not a good scheme, that is
all.

I am sure we can find a better scheme that can achieve the result and
still is fail safe.

Simo.

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



More information about the devel mailing list