Nsss: A secure NSS-like implementation for static linking | Hacker News Reader

Nsss: A secure NSS-like implementation for static linking

skarnet.org

53 pointsfanf226 comments

> That daemon should be set up by the system administrator.

One of the reasons why nsswitch runs in the client process is that the modules may very well need access to files that are only readable by the user (kerberos tickets...) or in other ways depend on the authority of the user process. Running this as a system-wide daemon makes such things hard to do as it requires reimplementing security checks that simply work in the in-process case and may very well lead to the daemon having to run with particularly high privileges (read arbitrary files, inspect arbitrary processes...).

Yeah, but this is not really a good design. The user's credentials need to be available to services like nscd. One way to do this is to run such services per-user, which then has the benefit of still being a least-privilege implementation.

That is mostly working system except the nss module might depend on stuff like environment variables or SELinux contexts. Also, when you introduce per-user services you are deep into the “reinventing systemd” territory. Interesting idea would be to spawn the service per-process on the first call that needs it as a child of that process, but it is questionable while it is really worth it in contrast to normal NSSwitch implementation.

I'm not reinventing systemd. On systemd systems, use systemd. On non-systemd systems, launch the process on demand from a privileged process that can do it (e.g., here `nscd` on a non-systemd system would have a call to start an instance on behalf of some UID, and the client library would call that when it can't contact the per-user instance).

> - musl only connects to nscd when it cannot find an answer in its files backend

ISTM that this should be fixed in Musl, that it should only check `files` first when it comes first in `/etc/nsswitch.conf`.

Also, if IPC to `nscd` were fast enough, then maybe nss should just always call `nscd`. Maybe this should be configurable in `/etc/nsswitch.conf`, then nss should only ever look in `files` when `nscd` is unreachable.

TFA essentially is this, but not in Musl. It's a fine workaround, but it ought to be implemented in Musl.

> - The nscd protocol does not support enumeration, so primitives such as getpwent() cannot be implemented over nscd.

Backend-agnostic enumeration isn't really useful. If you need to enumerate then you need code to talk to the specific backend(s) that you care about (e.g., files, LDAP, etc.).

skalibs version 2.14.0.0 or later. It's a build-time requirement. It's also a run-time requirement if you link against the shared version of the skalibs library.

s6 version 2.12.0.0 or later. It's a run-time requirement only, to run the nsssd service (and can be done without if you have a suitable replacement for s6-ipcserver).

I love that the anti-systemd crowd is implementing their own systemd.

well, of course to reach feature parity you have to implement it somehow. the question how they do it is a different can of worms.

i am glad they stopped complaining and do their own thing. i mean, this is opensource and free software about.

ska (and djb) libs have its own little world which, in some aspects, is weirder than systemd.

A most striking example is their time approach - they refuse to acknowledge 64-bit timeval and claim "those APIs will become obsolete in 2038" [0]; instead, they promote the TAI time, which is uses Unix epoch, except with bit 63 set and adjusted by leap seconds offset (whose value changes every few years or so, so old code needs to be patched or all timestamps would be a few seconds off). And this is not just internals; it's visible to users for example in log file names [1]

Now, I don't care if it's TAI or UTC, but I do think the working well with others is very important. And choosing a timestamp which is incompatible with basically every other piece of software out there is.. suboptimal.

[0] https://skarnet.org/software/skalibs/libstddjb/tai.html

[1] https://skarnet.org/software/s6/s6-log.html

> configurable user/group/shadow database access, providing getpwnam() et al. functionality by communicating over a Unix domain socket with a daemon

If this were compatible with the nscd protocol, you could use the daemon with unmodified musl (or appropriately configured glibc)… feels a bit like a missed opportunity?

> * The nscd protocol does not support enumeration, so primitives such as getpwent() cannot be implemented over nscd.

but the protocol could still be a superset, and musl wouldn't invoke the new parts of the protocol.

I'd love to see if there's some fundamental limitations of the protocol that prevent this, but nscd and its protocol are woefully underdocumented, and it's not even stable, technically, since it's part of glibc and the server and client can change their protocol whenever they want.

Making a new, properly documented protocol, independent from That One Libc You Want To Get Rid Of Anyway, is probably a good idea.

musl implements it, it's not "part of glibc" anymore in the sense of glibc having final control over the protocol. So it's stable for all intents and purposes.

The protocol has a version number (so no fundamental limitation), and is implemented in 500 + 170 lines of code:

https://github.com/pikhq/musl-nscd/blob/master/src/socket_ha...

https://github.com/pikhq/musl-nscd/blob/master/src/write_val...

Code isn't docs, but reading 670 lines of code is not "woefully underdocumented". Yes, a spec would be great. So, write one.

Especially since the work for the "new" protocol is the same - or is that equally underdocumented?

Backend-agnostic enumeration is not useful.

Isn't this just same as sssd? You got daemon with various backends, and then nss wrapper lib to query that daemon.

SSSD is an abstraction on top of NSS and PAM.

Most of the problems they list for nsswitch also apply to PAM, or am I missing something?

There's a lot more code calls getXbyY vs code that calls PAM.

Yup, PAM is a huge mess for the same reasons. The BSDs are a bit cleaner, but a daemon approach is likely the best approach.

Ohh, this looks nice. I've been wondering for a while why nobody had yet come up with a non-insane alternative to nss (whatever systemd cooked up need not apply), since the fundamental problem is fairly easy, if you're not in the position of the original NSS authors (i.e., "we just invented dynamic library loading and can't come up with a better example usecase").

> whatever systemd cooked up need not apply

systemd uses nss like everything else.

> since the fundamental problem is fairly easy

Very insightful. The problem is actually pretty complicated and requires runtime initialization, unless you forego all of the services NSS provides.

> systemd uses nss like everything else.

systemd has an nss alternative: https://systemd.io/USER_GROUP_API/

Systemd is accessible via NSS https://www.freedesktop.org/software/systemd/man/latest/nss-...

It's only an alternative if you connect to it directly (and why would you?). It's more an alternative to writing another nsswitch backend.

NSS is overcomplicated for 90% of use cases, and as another poster pointed out, that didn't stop systemd from trying to make it worse.

does this have the 2038 issue?

nsswitch != Network Security Services (NSS)

Reply on news.ycombinator.com