GNOME Bugzilla – Bug 729118
/usr/lib/passwd issues
Last modified: 2018-08-17 18:59:42 UTC
See this thread: https://lists.fedoraproject.org/pipermail/devel/2014-April/197783.html There are three cases where the uid matters: 1) /etc files owned as non-root 2) set{u,g}id binaries in /usr 3) /var - the systemd-tmpfiles snippets need to be able to look up uids Now, RPM ships names in packages - during install, it runs useradd, and then looks up the name -> uid mapping when calling chown(). Effectively, the name -> uid mapping is a transient per-machine state. We could do this with OSTree too. We would need some mechanism to allow trees to contain names instead of uid/gid. Because we can't break the data format, this would likely have to be some new file in the tree. Let's say /usr/share/ostree/dynamic-uids.variant. Then OSTree would process this at tree compose time, and *append* to a new file, /var/localsystempasswd. So we'd have: /etc/passwd: Human users /usr/lib/passwd: Static defaults from upstream /var/localsystempasswd: Dynamic system users It's not pretty. But it may be the least bad solution.
s/tree compose time/tree deployment time/ obviously.
In the general case, system users cannot be in /var, as we allow /var to be mounted late.
Note we'd only be talking about *dynamic* users - statically allocated users (e.g. "bin") would be in /usr/lib/passwd. But on the other hand maybe there's not a strong rationale for having both /etc/passwd and /var/localsystempasswd - OSTree can just write to /etc/passwd. Yeah, let's just do that. It means that /etc/passwd again contains a mix of human and non-human users, but oh well.
I'm increasingly feeling that I need to define a new OSTree format that contains symbolic names instead of uids. And on the client side, teach OSTree how to manipulate /usr/lib/passwd or /etc/passwd.
Ok, since this bug, systemd-sysusers has been introduced: http://cgit.freedesktop.org/systemd/systemd/commit/?id=1b99214789101976d6bbf75c351279584b071998 The more I think about it, as long as we're shipping numeric uids, there is no solution to the general problem that doesn't involve stateful allocation. (The general problem is where we add a user for a daemon, then it gets removed) For tree replication, that state needs to live on the compose server. And thus solving it becomes the problem of the tree composition tools. What's as yet unclear to me is whether we should enhance OSTree to ship symbolic names.
Furthermore, because OSTree ships numeric uids, we need force systemd-sysusers into building the same mapping. That means that projects like rpm-ostree will basically need to do a merge from their local state (which uids have been allocated) post-tree compose. * For both users and groups, we have a stateful mapping name -> uint on the compose server * At tree compose time, during postprocessing, loop over systemd-sysusers fragments (and for that matter, legacy writes to /etc/passwd). * If the user is already known, rewrite the sysuser snippet to include cached uid * If the user is not known, allocate a uid, add it to the cache, then rewrite sysuser snippet I'm pretty sure this will allow a functional replacement of nss-altfiles as things stand today.
OSTree has moved to Github a while ago. Furthermore, GNOME Bugzilla will be shut down and replaced by gitlab.gnome.org. If the problem reported in this Bugzilla ticket is still valid, please report it to https://github.com/ostreedev/ostree/issues instead. Thank you! Closing this report as WONTFIX as part of Bugzilla Housekeeping.