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. if you place system users in LDAP, then it's your own fault if things break, and we should strictly not support that. 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. > 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... Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
