On Fri, 2014-04-11 at 18:39 +0200, Lennart Poettering wrote: > On Fri, 11.04.14 15:49, Colin Walters (walters@xxxxxxxxxx) wrote: > > > On Fri, Apr 11, 2014 at 10:34 AM, Lennart Poettering > > <mzerqung@xxxxxxxxxxx> 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
