On Mi, 23.04.25 14:33, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> > > > Then we should do what the SUSE people did and move packaged versions > > > > of those things to /usr instead. Or make the system work with drop-in > > > > files, or a number of other things. > > > > > > Please specify what exactly you mean by "move packaged versions to /usr". > > > a) just move, keeping the ownership intact > > > b) move, but chown root:root > > > > > > If b, then yes, this is the "preferred solution" in my original mail. > > > If a, then this doesn't help :( > > > > > > > Yes, I meant (a) but I was referring to the users and groups data. If > > the problem is dealing with debian-style three-way-merges that > > rpm-ostree and bootc do, then we should obviate the need for them. > > Just moving things doesn't help. The first immediate issue is that the > appropriate tools (nss-files) do not support those separate locations. > This can be solved, e.g. by nss-altfiles. (Systems built with rpm-ostree > configure nss-altfiles, but not everything else does.) But the bigger > problem is that even if nss supports both sources, it is still possible > to have a conflict when the two lists are managed independently. > > See the scenario described in the original email: package foo has user > 'foo' (999), and files in the image are owned by 999. The local admin > creates user 'bar' (998). The image is rebuilt and we get user 'foo' > (998). Now we'll have 'foo' (998) defined in /usr/somewhere/passwd, and > 'bar' (998) defined in /etc/passwd. The move hasn't helped, no matter > how we resolve the conflict, one or the other side is going to be > unhappy. Also: note that various tools that "offline" access a disk image typically don't understand such secondary databases. Specifically, systemd-sysusers' --root= and --image= support will never consider those secondary databases, and hence if you invoke the tool like that might create conflicting users. (It's of course fine to say, that "offline" systemd-sysusers operation is not supported on OS images of your distro, but I am pretty sure there are many other tools like that in a similar situation, and not sure you want to rule out all of them. systemd-firstboot's --image=/--root= tool also wouldn't work btw, nor systemd-tmpfiles --image=/--root=). Again, I am not sure I grok why ostree insists on managing /etc/passwd with two sets of tools. The conflict they are running to is rooted in that original sin of trying to have it both ways: /etc/passwd managed by systemd-sysusers and by their ostree thing. 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
