> 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.
> - 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.
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.
> 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?
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").
> 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.
1 reply →
> - 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.
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
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.
> 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.
2 replies →
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/
1 reply →
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)