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

Colin Walters walters at verbum.org
Fri Apr 11 06:33:59 UTC 2014


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.

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 =/

One way to fix this that goes with my general direction of moving 
things out of %post into systemd: a dynamic uid reservation system that 
saves state persistently.  

Crudely, this would be ExecStartPre=/usr/sbin/useradd -r ...
except we'd wrap that with something that checked whether the user 
existed first.

Then /etc/passwd would still be local system-persistent state, and 
OSTree still wouldn't need to run a %post.  I think though it'd be good 
to still use /usr/lib/passwd in this model for daemons that *don't* 
save state persistently, like dbus.  No need to pollute /etc/passwd 
with them.

(Note, we'd also need to teach %systemd_preun to run some kind of 
ExecUninstall=, or skip spawning subprocesses and teach systemd how to 
modify the user database directly)

Thoughts?



More information about the devel mailing list