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

Miloslav Trma─Ź mitr at volny.cz
Fri Apr 11 17:05:14 UTC 2014

2014-04-11 8:33 GMT+02:00 Colin Walters <walters at verbum.org>:

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

"Clearly not."

There is broad agreement that future access to the user database database
(both reading and writing) will be through sssd[1], and that the data model
of /etc/{passwd,shadow} is too restrictive--we already want/need to store
more data about users than those files allow us to.  (E.g. language for
physical persons, better namespaces and more accurate password expiration
for all accounts.)

So, having /usr/lib/passwd storing the same limited set of data is not the
right long-term thing.  Unfortunately, AFAIK the fuller interface isn't
ready yet.

> The main case where it breaks is when you have a daemon that runs as
> non-root and saves state, so you give it its own system user, but not a
> reserved uid.  Daemons in this class will have their uids effectively
> ordered by package installation order =/

Other posts of the thread have brought up the issue of files owned by the
same account.[2]

In the really-long-term, really-hand-wavy, future, I think we need to move
away from the 32-bit UIDs[3], and instead use something much longer and
FEDORA_DAEMON_ACCOUNTS/$name, LOCAL_USER/$name, $windows_domain_name/$sid);
that would give us a much larger namespace, avoid SID->UID mapping
problems, and we could just do the allocation at packaging-time, using
FEDORA_DAAEMON_ACCOUNT/$name both in RPM metadata and a password database
snippet, without having to worry about overflowing the reserved 1000 UIDs.

AFAIK nobody is working on this, and it would be a huge change, so that's
not going to help in the medium term.

[1] With really-early-boot-before-sssd processes using ~the existing glibc
interfaces and files to avoid a dependency loop.

[2] Overall I'm *strongly* convinced that the fully-stateless ==
fully-atomic-updates model is simply unworkable.  We can have
stateless/atomic software installation, but we *absolutely do* need to
allow for arbitrary operations to be done on system's state between loading
the new version on disk and starting it.  Fedora-atomic can have special
support for a few classes of state know in advance, but fully general
software needs fully general post-installation adjustments.  (E.g., where
does ALTER TABLE ADD COLUMN on software upgrade fit in the Fedora-atomic

[3] This could work in the same way SELinux contexts now work in the
kernel, having a 32-bit UID as an internal identifier that changes between
reboots, and longer usernames as the long-term storage mechanism.  New
syscalls would work directly with usernames; older applications would still
work with the UIDs and the APIs would work as long as they don't try to
store the UID values anywhere.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140411/dcb24e77/attachment.html>

More information about the devel mailing list