Nolibc: a minimal C-library replacement shipped with the kernel

Posted Jan 24, 2023 11:53 UTC (Tue) by dezgeg (subscriber, #92243)
In reply to: Nolibc: a minimal C-library replacement shipped with the kernel by mjg59
Parent article: Nolibc: a minimal C-library replacement shipped with the kernel

Supporting NSS via other way besides dlopen() from arbitrary process is almost fully implemented already - nscd. I don't get why that approach isn't used more widely. It would solve other problems also, for example having to have both 32-bit and 64-bit .so:s of every NSS module.

Nolibc: a minimal C-library replacement shipped with the kernel

Posted Jan 24, 2023 14:34 UTC (Tue) by joib (subscriber, #8541) [Link] (3 responses)

nscd is mostly dead these days, e.g. https://fedoraproject.org/wiki/Changes/DeprecateNSCD and https://www.fedoraproject.org/wiki/Changes/RemoveNSCD .

Using NSS makes it relatively easy to replace nscd with something modern like sssd and systemd-resolved like the above deprecation issue mentions, without having to have a big flag day and recompile $WORLD. ;)

Nolibc: a minimal C-library replacement shipped with the kernel

Posted Jan 24, 2023 18:55 UTC (Tue) by dezgeg (subscriber, #92243) [Link] (2 responses)

I don't understand where "big flag day and recompile $WORLD" would be needed. nscd is a client-server system over UNIX sockets, so "to replace it with something modern" you'd just replace the server part with something that speaks the same protocol.

In fact, someone already has done such a server reimplementation of the nscd: https://github.com/pikhq/musl-nscd - and apparently musl does support talking the nscd protocol (TIL, I thought it really does only basic /etc/passwd et al reading).

So if that musl-nscd project actually is mature and well-maintained, then sounds like musl has a superior NSS implementation to the glibc one - one that works from statically linked binaries (unlike glibc), doesn't need installing 32-bit versions of all NSS modules separately, and no risk of mess of NSS modules potentially loading incompatible shared objects with the user program.

Nolibc: a minimal C-library replacement shipped with the kernel

Posted Jan 24, 2023 21:07 UTC (Tue) by joib (subscriber, #8541) [Link] (1 responses)

I'm not very familiar with the nscd socket protocol, but I'm not sure it does everything needed considering nscd does only caching and not lookups, which is why we get these backwards setups where things like ldap and tls libraries are mapped into the client process address space, and each client is responsible for looking up stuff independently if the entry is not found in nscd. Luckily e.g. sssd fixes that architectural misstep, but, well, that's sssd and not nscd.

Also, IIRC nscd relies on the client process mmap'ing the cache DB, the socket protocol is only used as a control protocol and actual data is accessed via mmap?

In an ideal world NSS could instead, back in the day, have been designed as a set of well-designed unix socket interfaces, and then individual daemons would be responsible for lookups, caching etc. (with perhaps an exception for a built-in local /etc/{passwd,group} implementation). Oh well.

Nolibc: a minimal C-library replacement shipped with the kernel

Posted Jan 25, 2023 16:43 UTC (Wed) by dezgeg (subscriber, #92243) [Link]

At least to the extent musl uses nscd, that part of the protocol seems just sensible request-response one: https://github.com/bminor/musl/search?q=nscd (1st one having __nscd_query).

It does appear to be the case that the protocol allows some craziness like the client can query the file descriptors of the cache files (via SCM_RIGHTS fd passing over Unix sockets): https://github.com/lattera/glibc/blob/895ef79e04a953cac14... . Musl doesn't seem to use so maybe not everything is supported, or maybe that is some weird attempt at optimization to reduce IPC overhead.

I do know that for sure (at least in the past) glibc does support doing the lookups from the nscd daemon because I have setup such a system in the past. That is, libnss_foo.so were located outside the usual library search path, so any application wouldn't find and dlopen() it. Then, the directory containing libnss_foo.so was added to LD_LIBRARY_PATH of nscd.service. I don't remember anything being broken (for a basic LDAP logins use case).

(That was on the NixOS distribution, where there is no global /lib and multiple versions of every package, including glibc, can coexist on the system. So in-process NSS module loading quickly leads to disaster).

> In an ideal world NSS could instead, back in the day, have been designed as a set of well-designed unix socket interfaces, and then individual daemons would be responsible for lookups, caching etc. (with perhaps an exception for a built-in local /etc/{passwd,group} implementation).

That's the thing - from what I can tell nscd-the-protocol is basically 80% of the way there! But sadly there seems to be no interest in glibc side. Maybe there is hope for musl folks to improve it (maybe by taking and documenting the good parts of the current protocol and then speccinc and implementing any needed extensions and hoping that glibc would eventually implement those).