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...). 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. 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. 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
