[systemd-devel] new user/group population on bootup

[Colin Walters]

Hi,

I had a quick look at the new:
http://cgit.freedesktop.org/systemd/systemd/commit/?id=1b99214789101976d6bbf75c351279584b071998
and followon commits.

My high level takeaway right now is that this looks OK for nspawn
containers, but it's not clear to me it's viable or right for the host
OS, at least for general purpose systems.

My perspective here comes as OSTree maintainer, which is an updater that
replicates filesystems.  Here's the bug on the related issue:
https://bugzilla.gnome.org/show_bug.cgi?id=729118

* Is the vision of an empty /etc right for the host?  It's not clear to
me...if you look at a typical general-purpose system, there's...lots of
stuff in there =)  We'd be talking about lots of work across many
projects.  Particularly stuff like PAM.

What OSTree does is a "rebase" of /etc across updates.  It takes the
*new default* /etc from /usr/etc (could be /usr/share/etc), and then
applies your *changes* on top (on a whole-file basis, it doesn't attempt
semantic merging). The essential property here is that you get new
default config files.  Even if we're headed towards cleaning /etc,
there's still going to be software that adds new files there for a while
- a solution for a general-purpose OS is going to have to handle this.

Are you thinking of removing the config files in /etc/systemd/ like
logind.conf?

* Static versus dynamic UID allocation: OSTree curently replicates
numeric uid/gids, and so does other "image-like" update systems like
Omaha or "btrfs send".  The bits committed to systemd use dynamic
allocation.  Now, that's OK as long as the service doesn't have files
owned by that uid/gid in /usr or /etc.

polkit is an example of software that is currently dynamically
allocated, and has /etc/polkit-1/rules.d owned by that user.  We should
think about whether anyone doing FS-level updates needs to somehow
integrate with systemd's sysusers to chown() files, or whether we need
to ban files in /etc and /usr owned by dynamic uids.  The discussion on
fedora-devel-list was here:
https://lists.fedoraproject.org/pipermail/devel/2014-April/197819.html