On Di, 15.04.25 14:27, Colin Walters (walt...@verbum.org) wrote: > 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.
No, not at all? I have been dealing with immutable systems for a bit, and as long as /etc/passwd is retained together with the rest if /etc/ and /var/ you can update /usr/ pretty freely? There are very few files in /usr/ that are owned by non-root, thankfully, so that it is easy to use static UID assignments for those users (though I think they should just be fixed to not do this, at all; it's usually about suid/sgid, and that's a terrible idea anyway). I don't understand the problem at all to be honest, but believe me if this is an issue at all it seems to be an ostree/bootc issue, not a general one. Please do not make claims about "every" image based update system please. > 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". Hmm? You want to run /var/ from one installation together with an /etc/passwd from a different installation? or how am i supposed to understand that? I am pretty sure one should always carry around /var + /etc as a unit, precisely because they reference each other in various ways, including UID/GID ownerships. > > 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. What's the usecase for something like this (doc doesn't mention any?)? This sounds really really pointless to me? I can see scenarios where /etc/ is "more" persistent than /var/, but the opposite seems very very strange to me, and the system is simply not designed for that. It seems you are just creating this artificial problem for yourself with this? BTW: note that the UID column of sysusers.d/ snippets actually can take a path in the fs instead of a numeric UID. If you really want to do weird stuff, such as flushing out /etc/ on boot (though I seriously don't grok why in heaven you'd do that? you are just shooting off the legs you stand on that way), then you could just reference paths in /var/ there: if that path exists, the UID to use for the newly created user is taken from its ownership – if it doesn't exist the UID is allocated dynamically. This should be able to address your issue? Lennart -- Lennart Poettering, Berlin -- _______________________________________________ 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
