On Fri, 2014-04-11 at 19:01 +0200, Lennart Poettering wrote:
On Fri, 11.04.14 12:47, Simo Sorce (simo(a)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