Re: Supporting sssd, preparing for nscd sunset

[Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de>]

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