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

Lennart Poettering mzerqung at 0pointer.de
Fri Apr 11 14:34:06 UTC 2014

On Fri, 11.04.14 06:33, Colin Walters (walters at verbum.org) wrote:

> For the fedora-atomic work, the only not-in-Fedora package is
> shadow-utils because it requires a patch, that still lives in my
> walters/rpm-ostree COPR.
> Patch is linked from my post here:
> http://lists.alioth.debian.org/pipermail/pkg-shadow-devel/2014-March/010099.html
> Also, some discussion in the glibc bug:
> https://sourceware.org/bugzilla/show_bug.cgi?id=16142
> What I'd like to open is a discussion about whether /usr/lib/passwd
> is the right thing long term.  I think it'd be very useful to
> support it short term, but it's not perfect.

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, 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, for example for setting up rsync-based backup
schemes, or to manipulate group membership for system users).

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.

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. With that in place we can support schemes
where a "factory reset" of the system can be easily done by simply
flushing /etc and /var altogether and then repopulating it from this
data. THis is particularly useful in order to run 1000s of container
instances off the same /usr tree, where the instance-specific /etc and
/var is created as needed when the container first boots up. 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).


Lennart Poettering, Red Hat

More information about the devel mailing list