fedora-atomic discussion point: /usr/lib/passwd

[Colin Walters]

On Fri, Apr 11, 2014 at 10:34 AM, Lennart Poettering 
<mzerqung at 0pointer.de> 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.

>  where the admin
> must be able to set the password, but applies to a lot of other cases
> too (for example, it is common practice to set passwords, shell, home
> dir for database users, 

Yeah.  But admins can copy the user data to /etc/passwd, and that wins. 
 That seems fine to me.

> Hence I strongly doubt that immutable, vendor-supplied password files
> can ever work. The goal here must be to declaratively *populate* the
> initial password file from some vendor-supplied table, but not to
> *equate* them, if you follow what I mean.

Hmm.  Is there a reason you prefer that instead of an "equate but with 
overrides" model?

> Within the systemd project we have been working on a scheme we call
> "factory" where packages can drop in static descriptions in /usr/lib 
> of
> stuff they need in /etc and /var to work properly. The idea is to then
> use this information automatically at boot if systemd finds /etc and
> /var empty to populate them.

The problem is that I need daemon users to be added (and removed) even 
*after* system installation.  This can occur when simply upgrading, or 
when switching trees, or when adding packages on top of a base tree.

>  THis is particularly useful in order to run 1000s of container
> instances off the same /usr tree,

If your container tree is immutable, then I can see that working, but 
do you see supporting dynamic changes to the container content?  If so 
it's the exact same situation with ostree.

Now maybe with containers you don't care about atomic upgrades, and 
furthermore while you're running arbitrary %post code as root, at least 
it'd be in a container and not actually operating live on your root 
filesystem.

> These "factory"
> files would support pretty much two directives only: one to create
> system users/groups with specific parameters (with the numeric 
> UID/GID possibly
> sourced off the stat() data of some other file in /usr, so that we can
> support suid/sgid binaries nicely), and another one to copy files that
> are strictly needed for boot into /etc).

Hmm...I'm going to reply to Martin on this point.