[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)

Yep, Anaconda performs the `authselect` kickstart command (that allows for setting up NSS and LDAP) on the files inside the target chroot, not in the ramdisk image where the installer itself is running. That means, the preloading trick that RPM used to do (in order to utilize the host's NSS modules) wouldn't be useful in this context anyway, since there's no such thing as a host NSS setup here.

The trick itself probably never worked anyway since it only preloaded the `files` module (by querying the `root` user which is supposed to only exist in `/etc/passwd`), and that NSS module actually seems to be chroot-aware (whether intentionally or not), by re-reading those files from disk on subsequent lookups, i.e. after RPM has entered the target chroot and does the actual lookups when laying down files.

> In post, the system is already configured but then it's also running _in_ the newly installed OS rather than anaconda environment.

To be precise, this assumption seems to be incorrect because kickstart `%post` supports `--nochroot` as well :sweat_smile: so you could have something like:

```kickstart
authselect select sssd
%post --nochroot
dnf install --installroot=/mnt/sysimage some-package
%end
```

But that doesn't change the fact that the NSS setup (`authselect` above) happens inside the chroot, not outside of it, so you couldn't ever hope for RPM to reuse that setup when called that way.

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

Message ID: <rpm-software-management/rpm/pull/4085/c3759957772 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20260116/872a7885/attachment.htm>