Colin, Seem to me the problem here is clearly that ostree can't support dynamic uids, so it should not try.
I see only two solutions: 1. Create a file that assigns permanently UIDs for all the packages you know about that currently assign uid dynamically. This solves the problem entirely for all you know about. 2. Deploy a /usr/passwd file to be merged into the system passwd (or via a clever nss module at runtime) at ostree creation time where dynamic uids are assigned at installation. Note that (2) is weak because you can still have a new image change the order of assignment, so on upgrade of an existing system image, if an assignment changes, you may have ownership of files based on the previous passwd (in a preserved data partition), just break. I think ostree necessarily depends on (1) for good behavior, unless you can ensure data never needs to be persisted. Anything else won't really work well, and is just a band-aid. HTH, Simo. On Mon, 2025-04-28 at 10:32 -0400, Colin Walters wrote: > > On Mon, Apr 28, 2025, at 5:33 AM, Lennart Poettering wrote: > > > This is clearly a bug in ostree if you ask me: /etc/passwd should > > under no cicumstances be flushed out entirely: once deployed it must > > remain local configuration. > > There is no special casing for /etc/passwd in ostree. > There is only: > > - ostree's generic /etc handling for all files there > - nss-altfiles: https://github.com/aperezdc/nss-altfiles > > The latter of which is also used by Flatcar (ref > https://github.com/flatcar/nss-altfiles ) > > Flatcar also has a similar approach to /etc though using overlayfs - which > also doesn't special case /etc/passwd. > > > It's really weird to me that ostree seems to manage /etc/passwd in two > > distinct, conflicting ways: once via systemd-sysusers, and once via > > their ostree stuff. They should figure out that conflict, and decide > > which path to go. > > It's complicated by the potential to have floating UIDs in content in the > image, that's why we're talking about it. > > > Sorry, but I don't accept at all that this was a universal > > problem. It's clearly not: it's a problem ostree has created for > > itself, and should address for itself. > > For sure, this problem doesn't exist for systems which are fully hermetic > /usr and don't have any dynamic UIDs in the /usr content. (Actually though, > the hermetic /usr is mostly equivalent here to "hermetic / with stateful > carveouts of /etc and /var" which is what bootc/ostree encourage now) > > Stated conversely, I would say it's a pretty universal problem with anything > trying to ship systems that have dynamic UIDs owning content they want to > ship in the image, which describes some Fedora RPMs today, as well as 3rd > party ones. (And to be clear, "image" here meaning shipping UIDs on the wire, > not usernames) -- Simo Sorce Distinguished Engineer RHEL Crypto Team Red Hat, Inc -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
