Hi Ludo, thanks for getting the discussion started. This problem has been weighing on me for the past months and I don't see a good way forward.
Ludovic Courtès <ludovic.cour...@inria.fr> writes: > For the record, glibc maintainer Carlos O’Donell brought up our use case > a while back on the glibc mailing list but it wasn’t particularly well > received: > > https://sourceware.org/pipermail/libc-alpha/2022-February/136741.html DJ Delorie's response makes it sound like they would prefer that all of the host system's NSS *configuration* (alongside the NSS modules) be duplicated in the Guix "container", because that's not guaranteed to be compatible. That's not a way forward for us, because that would make running Guix-built software much harder and require significant configuration on the side of the user. > [...] If sssd becomes dominant, we > might just as well arrange to have NSS always load libnss_sss.so. What are the other contenders here? I assumed that sssd was what everyone™ used nowadays. At the MDC we've been using sssd on RHEL for a long time and we've seen some problems with the naïve approach of just having the Guix System's NSS load libnss_sss.so: - In a Guix System VM we also had to explicitly set LD_PRELOAD or LD_LIBRARY_PATH in the current environment (not just nscd's environment) to make things like "id" work. Having just NSS load the library was not enough to work with user accounts that are defined in LDAP, for example. - A different Guix System VM was configured to use nss-pam-ldapd. Upon reconfigure it attempted (and predictably failed) to delete all user accounts on LDAP, because none of them were defined locally. I guess Guix System needs to be a little less eager to manage remote accounts that NSS plugins (including sssd) say exist. - PAM in a container. While this is not strictly related to the disappearance of nscd, it is another obstacle relating to sssd. On foreign distros I use Guix containers that bind-mount the host system's /var/lib/sss/pipes directory. The hope was to use a native Guix build of libsss to talk to the socket at /var/lib/sss/pipes/pam (and potentially others) for authorizing users via the host system's sssd infrastructure. In "guix shell -C" this won't work, because sssd refuses to talk over that socket if the ownership is not root:root. In the Guix shell container there is only ever *one* user account, so root-owned files are assigned to the overflow user account, and thus communication with the host system's pam socket is impossible. I failed to fix this with subuids, because the "guix shell -C" process does not have sufficient privileges to map more than one user id. I'll note that /var/lib/sss/pipes also contains an "nss" socket; I don't know if it checks ownership on that socket, but it's possible that it also cannot be used in "guix shell -C". -- Ricardo
