[Rpm-maint] [rpm-software-management/rpm] Make user/group info reliable operation across chroot (PR #2503)

[Colin Walters]

cgwalters left a comment (rpm-software-management/rpm#2503)

We should probably track rpm+chroot discussions in a dedicated issue, but the other really big thing about `chroot()` is that it massively complicates using rpm as a library because the process basically cannot reliably do anything else (in another thread) while a chroot is active.

We've mostly gotten away with things so far because the 90% case for e.g. dnf and PackageKit type software is operating on the live root, so it's just `chroot(/)` which is a no-op, so things are fine.

And most things using `rpm --installroot` are headless scripts that aren't doing anything else.

But for e.g. rpm-ostree, we *always* operate on an alternative root by default, we don't live mutate the running system. And in rpm-ostree we always act as a DBus daemon exposing progress information, etc. These two things combined are among the biggest reasons rpm-ostree doesn't use the main librpm transaction code (installing files and running scripts). In the end this is would likely be possible to work around by forking a dedicated helper process that runs librpm code and talking to it over IPC, ensuring that IPC layer is "thin" and never e.g. loads anything dynamically from the filesystem at all after starting (config files, or invoke gettext() etc).

But it'd fix a whole lot of things at once if rpm stopped using chroot(), and then we could go back to using NSS just fine.




-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2503#issuecomment-2674772849
You are receiving this because you are subscribed to this thread.

Message ID: <rpm-software-management/rpm/pull/2503/c2674772849 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20250221/d133ba86/attachment.htm>