On Tue, Apr 29, 2025, at 2:00 PM, Simo Sorce wrote: > Colin, > Seem to me the problem here is clearly that ostree can't support > dynamic uids,
First an important thing to understand is that while ostree will continue to be supported for quite a long time, lately we're aiming that the current use of ostree for host systems is a backend for bootc (implemented today), and that backend will eventually change to be composefs (ref https://github.com/bootc-dev/bootc/issues/1190 ). So limitations of ostree's wire format don't need apply here, and as already noted we have the interesting situation today that for OCI images (as consumed by both bootc and container runtimes like podman/docker/etc) the tar format already supports symbolic usernames. (Tangential but relevant: ostree's wire/storage format is intentionally very strict and non-extensible because it's designed to be checksummed as a Merkel tree, like git, and unlike tar; but the advantages/disadvantages of that wire/storage format don't matter with OCI) Anyways, the interesting thing is how we might extend dynamic ownership into OCI. I extended my comment in https://github.com/bootc-dev/bootc/issues/1263 > 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. Can you elaborate on "a file"? We already have multiple types of files related to this, from /etc/passwd to nss-altfiles to systemd-sysusers (and systemd JSON user records).? > > 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. That's what nss-altfiles is. Not quite sure about the difference between your 1 and 2 here. > > 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. I think the proposal of doing a dynamic chown as discussed in the bootc issue would result in the least surprise and would likely work well - at least for `/etc` which solves most of the use cases here (keylime, polkit (before it was made static)) etc. Still though needs some more thought for sure... Besides that though, I think it's a combination of: - Docs for the existing state - Improved warning tooling to understand potentially broken states (already in progress on bootc side) - Slowly porting projects away from having dynamic user ownership for content shipped in `/usr` (most important), then `/etc` (important but can be mitigated more easily). Files in `/var` should move to systemd-tmpfiles in general. -- _______________________________________________ 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
