On Fri, 2014-04-11 at 19:01 +0200, Lennart Poettering wrote: > On Fri, 11.04.14 12:47, Simo Sorce (simo@xxxxxxxxxx) 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
