C library system-call wrappers, or the lack thereof

Posted Nov 13, 2018 1:55 UTC (Tue) by fartman (guest, #128226)
In reply to: C library system-call wrappers, or the lack thereof by Cyberax
Parent article: C library system-call wrappers, or the lack thereof

For NSS, I've thought of two things:

*) There's a NSSS project already from Laurent that provides NSS compatibility for it https://github.com/skarnet/nsss

*) Another is using FUSE modules that provide a NSS API to existing modules and on read requests show a merged version of everything in the specific files (for example, a fuse-passwd could be mounted on top of the regular /etc/passwd and any requests to read() mean it will supply a merged version of all user database and then the libc function just parses from it as usual).

C library system-call wrappers, or the lack thereof

Posted Nov 13, 2018 2:10 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

NSSS is the correct approach. FUSE is not going to work, a lot of NSS modules can't enumerate entries, only resolve them.

C library system-call wrappers, or the lack thereof

Posted Nov 13, 2018 11:36 UTC (Tue) by nix (subscriber, #2304) [Link]

Even there, you could expose such databases as directories with the execute bit turned off. (But... nothing would know how to read such things, and you could indeed not export it as /etc/passwd, so you lose backward-compatibility, and while very Plan 9, I'm not sure that 'could' in this case corresponds to 'should'.)

C library system-call wrappers, or the lack thereof

Posted Nov 13, 2018 15:41 UTC (Tue) by quotemstr (subscriber, #45331) [Link] (1 responses)

What if my user database contains tens of thousands of entries? Why force programs to read (and parse!) all of those entries just to maintain the fiction that the user database is wholly described by a text file called /etc/passwd? NSS's goal is the right one. I'd implement NSS out-of-process instead of loading a DSO, but that's an implementation detail. A virtual text file is absolutely the wrong approach.

C library system-call wrappers, or the lack thereof

Posted Nov 13, 2018 16:28 UTC (Tue) by smurf (subscriber, #17840) [Link]

> What if my user database contains tens of thousands of entries?

That's benign. The really interesting part is when your user database is not enumerable, e.g. because you don't have the rights to do so.

C library system-call wrappers, or the lack thereof

Posted Nov 14, 2018 0:34 UTC (Wed) by sbaugh (guest, #103291) [Link] (10 responses)

glibc already provides an IPC-based API for NSS requests: nscd. If you disable caching, it's exactly what you want. nscd is backwards compatible to 1998 and is rock-solid. A number of platforms which allow shipping packages using a different glibc version from the "base platform" are already using nscd to achieve this separation: Nix, Guix, and some container platforms.

If you are enthusiastic about replacing NSS with an IPC-based API, please, promote use of nscd by default in Debian and Fedora! IMO, that's the only realistic route to achieve the goal.

C library system-call wrappers, or the lack thereof

Posted Nov 14, 2018 3:09 UTC (Wed) by quotemstr (subscriber, #45331) [Link]

Thanks for the reminder. I'd completely forgotten about nscd! I agree that deprecating all in-process NSS modules except for the nscd client would be a great path forward.

C library system-call wrappers, or the lack thereof

Posted Nov 14, 2018 6:16 UTC (Wed) by drag (guest, #31333) [Link] (8 responses)

> 1998 and is rock-solid.

That's news to me.

I probably had to restart nscd thousands of times across hundreds of machines. It was flakier then ntpd, which is saying a lot.

Nobody should be installing nscd anymore. It has always been terrible and it's always going to be terrible.

C library system-call wrappers, or the lack thereof

Posted Nov 14, 2018 12:42 UTC (Wed) by nix (subscriber, #2304) [Link] (7 responses)

It's been running nonstop for me without incident for many years (I use it to reduce the overhead of a big /etc/services so I only need to parse it once).

It is clearly not unreliable for many people, given that glibc upstream has been talking about replacing nss with nscd by default for some time now.

I think you need to investigate more....

C library system-call wrappers, or the lack thereof

Posted Nov 14, 2018 12:53 UTC (Wed) by smurf (subscriber, #17840) [Link] (6 responses)

It's been flaky in the past. I wouldn't use the nscd from 199x in any kind of production environment.

Today? no problem IMHO, and it does speed things up (a lot, for some installations).

C library system-call wrappers, or the lack thereof

Posted Nov 14, 2018 15:25 UTC (Wed) by zdzichu (subscriber, #17118) [Link] (3 responses)

Except when it doesn't work, which is a daily occurrence:

https://github.com/systemd/systemd/issues/10740

When allocating a dynamic user, a lookup is done in systemd, which fails (because the user doesnt exist, and systemd is going to allocate a dynamic uid for it) but then that answer is cached and after the dynamic user is set up, nscd will still say the user isn't created.

C library system-call wrappers, or the lack thereof

Posted Nov 14, 2018 16:40 UTC (Wed) by nybble41 (subscriber, #55106) [Link]

You can disable caching for some or all services in /etc/nscd.conf.

C library system-call wrappers, or the lack thereof

Posted Nov 14, 2018 19:01 UTC (Wed) by quotemstr (subscriber, #45331) [Link]

That's just an argument for moving nscd functionality into systemd. It's a coordination problem, not a conceptual problem with the protocol.

C library system-call wrappers, or the lack thereof

Posted Nov 15, 2018 16:05 UTC (Thu) by nix (subscriber, #2304) [Link]

systemd should flush the nscd cache when necessary (via nscd -i) if DynamicUser= is in use. This is not exactly subtle: it's half the contents of the nscd manpage in the man-pages package. :)

C library system-call wrappers, or the lack thereof

Posted Nov 14, 2018 17:05 UTC (Wed) by drag (guest, #31333) [Link] (1 responses)

I would rather just use sssd then any variant of nscd.

C library system-call wrappers, or the lack thereof

Posted Nov 15, 2018 16:07 UTC (Thu) by nix (subscriber, #2304) [Link]

nscd has one advantage which I don't know if sssd replicates: efficiency. Programs can query the cached names without actually talking to nscd at all, because it exports an mmapped region which programs can just read from as needed. Zero context switches! :)