[Rpm-maint] [rpm-software-management/rpm] Add back support for NSS-based user/group resolution (PR #4085)

[Michal Domonkos]

dmnks left a comment (rpm-software-management/rpm#4085)

> If we don't do that, glibc could try to load the modules from the chroot. Which could be something entirely incompatible. This goes back all the way to 1997 ([3a1f07d](https://github.com/rpm-software-management/rpm/commit/3a1f07df62827be18cd2d819896b2ae6cfd28cf3)) 😄

Oh, that's the commit :smile: Thanks, I did some git archeology but didn't find *that* one.

And yep, it would try to load them from the chroot *if* there's the `/etc/nsswitch.conf` file in there. Otherwise, it's actually the other way around - it would try to load them if we *do* this preloading :smile: The reason is that we effectively only do the preloading on the nss-files module (by looking up the `root` user) but glibc dynamically loads the needed modules as needed. So what happens (based on my observation so far) is roughly this:

1. Let glibc to read `/etc/nsswitch.conf` on the host and preload the nss-files module
2. Enter chroot
3. Look up a user - glibc now continues to use the nsswitch file from the host (doesn't reload it from the chroot) so it will first try to look at the files and if the user isn't there, it loads whichever module is the next, and *that* happens inside the chroot

So this is a bit more nuanced :sweat_smile: I need to look a bit closer at this, still.

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

Message ID: <rpm-software-management/rpm/pull/4085/c3754237536 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20260115/69818726/attachment-0001.htm>