On the removal of nscd from Fedora, and the future of nscd.

[Ludovic Courtès]

Hello,

Thank you Carlos for the introduction!

DJ Delorie <dj@redhat.com> skribis:

> "Carlos O'Donell" <carlos@redhat.com> writes:
>> Ludovic reached out to me regarding the removal because Guix uses nscd
>> for the interesting use case of supporting multiple system libcs:
>> https://guix.gnu.org/manual/devel/en/html_node/Application-Setup.html#Name-Service-Switch-1
>
> I think this is a weak argument.  If Guix can dlopen the host system's
> objects, you risk incompatibilities anyway.  And we don't have a rule
> that says that nsswitch modules have to be built against the exact
> version of glibc you're running against, although if the module is too
> new there may be problems.  But Guix would have this problem anyway if
> both sets of objects are available.  If Guix wants to run its own glibc,
> it needs to be isolated better - meaning, its own nscd, its own path to
> nss modules, etc.  Almost like a container or flatpack.  It may not even
> be able to parse /etc/nsswitch.conf if the host system is newer.

To be clear, Guix applications have been used on top of other distros
just fine.  This nscd requirement is one of the few must-haves to
ensure, as Joseph writes, that processes (in particular those linked
against Guix’s libc) do not end up dlopening arbitrary, possibly
incompatible libraries.

(The problem applies to other deployment tools that are not limited to a
single system libc such as Nix.)

I like the idea of keeping a trimmed-down nscd as Carlos wrote.  Calling
out to ‘getent’ would also work, but it potentially means having one
‘getent’ process per application, if I understand Florian’s proposal
correctly.

Thanks,
Ludo’.