Thanks for posting this! On Tue, Apr 15, 2025, at 6:55 AM, Zbigniew Jędrzejewski-Szmek wrote:
> This was a known problem for rpm-ostree systems, and was handled > ad-hoc when problems were reported, but is becoming a bigger problem > for bootc systems. To be clear though, I think this is a generic issue affecting *every* image based update system that wants to maintain some persistent state. And really backing up even farther, one reason we have some static allocations for packages today is basically because people wanted to share their data across NFS in some cases. The "sharing across computers" is in many ways the same problem as "sharing across distinct builds of an image". Now forgetting about bootc for a minute, if I go to take a set of RPMs and turn them into a qcow2/AMI - as we've done forever - the UID/GID allocations may not be the same across distinct builds depending on the package set either. However, the model so far has been that these "disk images" are just bootstrap tools, and thereafter one uses e.g. dnf to upgrade them, which ensures future RPM content carries forward those same allocations. However, that's not an image based *upgrade*. The system can and will drift over time from that initial disk image state. (rpm/dnf are actually totally unaware really that their initial state came from a disk image at all, its version, etc) A lot of the value I think in what we're doing in image based updates in going to a "controlled mutability" model is about being able to minimize drift over time. Putting together, see this blog: https://blog.verbum.org/2020/08/22/immutable-%E2%86%92-reprovisionable-anti-hysteresis/ But yes, with these uid/gids we've effectively introduced a new form of drift and it'd be great to minimize; moving to systemd-sysusers and systemd-tmpfiles helps a lot, but doesn't solve things in all cases. > There are a few options possible: avoid using any "owned files" in > packages, use tmpfiles.d to adjust ownership dynamically, switch back > to soft-static uid/gid assignments, completely change how we do > deployments, stop upgrading image-based deployments… We need to do > _something_, but it's not clear at this point what the best course of > action is. I think there's a mix of actions here. For some components/packages today, the *only* owned file they have is in /var for something like logs/state, and handling that is relatively straightforward - move the ownership out of RPM and into tmpfiles.d, allocate the user with sysusers.d. Then the content in the container image is purely root owned. That said, there is a giant wrinkle here in that in many cases we'd like to enable a "transient /etc" model https://bootc-dev.github.io/bootc/filesystem.html#enabling-transient-etc but that can then return the user/group drift problem again because sysusers is going to run on each machine. sysusers.d already has an "allocate based on this file path" but we'll probably want to extend that to not fail if the file doesn't exist yet. > This problem is now primarily visible for rpm-ostree and bootc, but > would appear also for any image-based system where the image is built > "remotely" (with a independent user/group database, even if the build > happens on the same machine), and the creation of local system > accounts is allowed. One example is ParticleOs [6], where this issues > is solved by _not_ allowing any "owned files" in the image and using > tmpfiles.d snippets instead. A valid solution, but one that obviously cuts out a lot of the current ecosystem. At least as of recently at least `bootc container lint` learned to warn about users-without-sysusers (ref https://github.com/bootc-dev/bootc/pull/1111 ) and we are looking to extend it to warn about this "floating uid with owned content" case explictily. > Nevertheless, even if we were to switch to soft-static allocations for > packages, soft-static assignment cannot cover users created by > non-distro packages and outside of packages. With bootc, it is easy > for a user to create some user or group in the image (via > 'RUN groupadd -r foo' or by installing some 3rd-party package). > So this becomes a bigger problem then previously, see [5]. Right. > We could also consider some bigger changes, like not using numeric > uids/gids for bootc images, and making the assignment only during > installation, similarly to how rpm does this… Yes, this is https://github.com/bootc-dev/bootc/issues/1263 - it would take us a bit away from "image based", but only slightly and would greatly help the problem. I hope to put it on the near term roadmap. > > At this point, I think the approach of combining the first two > solutions, i.e. minimizing the number of "owned files" and judiciously > using tmpfiles.d to adjust ownership at runtime is a feasible and > relatively painless option. To solve the problems for > rpm-ostree/bootc, we'd need to make this into an official policy and > adjust some packages. Yes. -- _______________________________________________ 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
