On Tue, Apr 22, 2025 at 04:09:17PM +0200, Lennart Poettering wrote:
> On Di, 15.04.25 14:27, Colin Walters ([email protected]) 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?
As I wrote in the other mail, we're discussing the case where
/etc/passwd is *not* retained together with /usr.
> 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).
In Fedora, we have ~393 packages with "owned files". You are correct
that most of those files are not under /usr, and of those that are,
suid/sgid is the common reason. But with that many packages, all kinds
of things happen.
(For example:
%attr(0644, root, pegasus) %{_unitdir}/tog-pegasus.service
WAT?)
But I don't understand why you think that only files under /usr are
important. If the files are in some other directory, and are part of
the package or image payload, they are subject to the same problems.
[snip]
> What's the usecase for something like this (doc doesn't mention any?)?
You're essentially asking "how does rpm-ostree work?".
I won't try to repeat the rpm-ostree/bootc docs inline here.
The design of those systems is fairly well documented online.
Please read those docs.
Zbyszek
--
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
