[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Supporting sssd, preparing for nscd sunset
From: |
Ricardo Wurmus |
Subject: |
Re: Supporting sssd, preparing for nscd sunset |
Date: |
Fri, 23 Feb 2024 22:48:16 +0100 |
User-agent: |
mu4e 1.10.8; emacs 29.1 |
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.courtes@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
- Supporting sssd, preparing for nscd sunset, Ludovic Courtès, 2024/02/23
- Re: Supporting sssd, preparing for nscd sunset, Felix Lechner, 2024/02/23
- Re: Supporting sssd, preparing for nscd sunset,
Ricardo Wurmus <=
- Re: Supporting sssd, preparing for nscd sunset, Maxim Cournoyer, 2024/02/24
- Re: Supporting sssd, preparing for nscd sunset, Picnoir, 2024/02/24