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

Carlos O'Donell carlos@redhat.com
Mon Feb 28 20:55:17 GMT 2022

In Fedora 36 we officially removed nscd from the distribution with this
system-wide change request:

I say "we" but it was the entire Fedora glibc team, which includes various
developers also on this list like Arjun, Florin, and DJ. We took this action
because over time glibc should focus on the important parts of being a core
runtime. We felt sssd and systemd had grown to the point where they were
well supported and and supporting nscd in Fedora was no longer required.

Ludovic reached out to me regarding the removal because Guix uses nscd
for the interesting use case of supporting multiple system libcs:

The idea is very clever in that if you always make the lookup in the system
nscd then the process with the alternative libc is decoupled from the system
libc and all the system plugins required to answer the lookup request.

Ludovic and I compared notes on the future of nscd, and we discussed a what-if
scenario. What if we kept nscd, but removed all the caches, and left it as a
daemon that could answer requests from system processes but the only goal was
to decouple the libc required to service the request and the libc in the process?

This is already starting to sound like Florian's getent idea where by a static
process uses a known binary to carry out the NSS lookup and resolution [1].

What if instead of getent we just thinned down nscd to something we could audit
and trust? If we really wanted to we could even compile the same code into getent
as a fallback e.g. try nscd first (long lived) then getent (short lived).

You might say "Well then nscd is mis-named!" I'd argue it's a "cache" for the shared
objects and state required to do the lookup, but not the data itself, and if you
didn't run nscd then you'd go through NSS normally, or "getent" if you were a
statically compiled binary.



[1] https://sourceware.org/legacy-ml/libc-alpha/2017-12/msg00831.html

More information about the Libc-alpha mailing list