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

[John Ericson]

Hi, I am coming from NixOS/Nixpkgs and this [PR comment] in particular.
I am *far* from an expert on this NSS, but I have been bitten by it on
a few occasions in conjunction with various sorts of sand-boxing, and I
certainly share the desire for more simplicity and security, hand in hand.

Specifically, it seems like this thread is reaching consensus anyways,
but wanted to back up a few things Ludo was saying.

On 3/3/22 08:40, Ludovic Courtès wrote:
> DJ Delorie <dj@redhat.com> skribis:
>> Ah, that's different - mostly.  It still means you're using the host's
>> /etc/nsswitch.conf, but that just exposes a different problem - how to
>> handle site-wide services in isolated "programs" (flatpacks, containers,
>> chroots, statically linked apps, Guix).

Yes. we have a chance to establish some new idioms here that can be used
in all those contexts (and Nix!). Good and exciting!

>> 
>> NSCD certainly could act as that gateway, but I'd hate to rely on it
>> without an RFC defining the protocol, and such an RFC would enable it to
>> solve the problem in a wider context too.
>> 

Stepping back, we can ask: "What makes a de facto standard?"

I would say a) stability and b) multiple implementations.

> Yes.  In practice, I haven?t seen nscd protocol changes in 10 years of
> Guix.

That's one, and a quick search turned up:

https://github.com/pikhq/musl-nscd

whose read-me says:

> musl-nscd is an implementation of the NSCD protocol. It makes use of NSS
> modules, just like with glibc. This permits alternative backends for the user
> and group databases for musl libc. The protocol it uses is a subset of that
> used by glibc. 

That's the other. Both criteria for "de facto standard" met!

>> Doing so, however, means that nscd (or some other equivalent) MUST be
>> present and running on all systems...
>> 
> Yes, exactly.

If I may push back on this slightly, a libc could should ship with the sssd and
systemd-resolved clients too. For sake of argument, one could imagine they are
even statically linked, so there is no dlopen to be suspicious of. The binary could
try those protocols first before falling back on the nscd protocol.

The goal here, I think, is to support the existing NSCD protocol as the "lingua
franca" we have *today*. It's not to hinder the uptake of anything else, or even a
value judgement on whether the NSCD protocol is "good" in any deep sense,
just acknowledging its what we've got.

----

Having found that musl-nscd, I was curious more generally what the Musl
community thought about this. I found [musl thread] which was referred to back
when the Fedora change was first proposed, and while the thread wasn't super
conclusive, I think it is broadly in agreement with what is discussed here:

- dlopen-ing arbitrary libraries is very bad
- static linking should work just as well
- Keep rump NSCD with caching and other inessential complexity removed

This [reply] a bit buried down from Rich seems to share the exact ethos about
just keeping NSCD for continuity's sake too. That's a good place to end.

Cheers,

John

[PR comment]: https://github.com/NixOS/nixpkgs/pull/155655#issuecomment-1055721088
[musl thread]: https://www.openwall.com/lists/musl/2020/10/19/1
[reply]: https://www.openwall.com/lists/musl/2020/10/23/15