5 ms·

Nsss: A secure NSS-like implementation for static linking

53 points by fanf2 2y ago

creshal 2y ago
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").
- candiddevmike 2y ago
  > 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.
  - agwa 2y ago
    > systemd uses nss like everything else. systemd has an nss alternative: https://systemd.io/USER_GROUP_API/ https://systemd.io/USER_GROUP_API/
    - lmz 2y ago
      Systemd is accessible via NSS https://www.freedesktop.org/software/systemd/man/latest/nss-systemd.html 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.
  - creshal 2y ago
    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.
eqvinox 2y ago
> 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?
- dundarious 2y ago
  > * The nscd protocol does not support enumeration, so primitives such as getpwent() cannot be implemented over nscd.
  - unilynx 2y ago
    but the protocol could still be a superset, and musl wouldn't invoke the new parts of the protocol.
    - creshal 2y ago
      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.
      - eqvinox 2y ago
        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_handle.c https://github.com/pikhq/musl-nscd/blob/master/src/socket_ha... https://github.com/pikhq/musl-nscd/blob/master/src/write_val.c 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?
deleted 2y ago
[deleted]
jwrteqhrwj 2y ago
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.
- deknos 2y ago
  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.
- theamk 2y ago
  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 https://skarnet.org/software/skalibs/libstddjb/tai.html [1] https://skarnet.org/software/s6/s6-log.html https://skarnet.org/software/s6/s6-log.html
zokier 2y ago
Isn't this just same as sssd? You got daemon with various backends, and then nss wrapper lib to query that daemon.
- candiddevmike 2y ago
  SSSD is an abstraction on top of NSS and PAM.
deknos 2y ago
does this have the 2038 issue?
account42 2y ago
nsswitch != Network Security Services (NSS)
dfox 2y ago
> 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...).
- cryptonector 2y ago
  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.
  - dfox 2y ago
    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.
    - cryptonector 2y ago
      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).
cryptonector 2y ago
> - 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.).
ximm 2y ago
Most of the problems they list for nsswitch also apply to PAM, or am I missing something?
- lmz 2y ago
  There's a lot more code calls getXbyY vs code that calls PAM.
- WhyNotHugo 2y ago
  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.

53 points by fanf2 2y ago

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").

candiddevmike 2y ago
> 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.
- agwa 2y ago
  > systemd uses nss like everything else. systemd has an nss alternative: https://systemd.io/USER_GROUP_API/ https://systemd.io/USER_GROUP_API/
  - lmz 2y ago
    Systemd is accessible via NSS https://www.freedesktop.org/software/systemd/man/latest/nss-systemd.html 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.
- creshal 2y ago
  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.

eqvinox 2y ago

> 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?

dundarious 2y ago
> * The nscd protocol does not support enumeration, so primitives such as getpwent() cannot be implemented over nscd.
- unilynx 2y ago
  but the protocol could still be a superset, and musl wouldn't invoke the new parts of the protocol.
  - creshal 2y ago
    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.
    - eqvinox 2y ago
      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_handle.c https://github.com/pikhq/musl-nscd/blob/master/src/socket_ha... https://github.com/pikhq/musl-nscd/blob/master/src/write_val.c 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?

deleted 2y ago

[deleted]

jwrteqhrwj 2y ago

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.

deknos 2y ago
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.
theamk 2y ago
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 https://skarnet.org/software/skalibs/libstddjb/tai.html [1] https://skarnet.org/software/s6/s6-log.html https://skarnet.org/software/s6/s6-log.html

zokier 2y ago

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

candiddevmike 2y ago
SSSD is an abstraction on top of NSS and PAM.

deknos 2y ago

does this have the 2038 issue?

account42 2y ago

nsswitch != Network Security Services (NSS)

dfox 2y ago

> 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...).

cryptonector 2y ago
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.
- dfox 2y ago
  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.
  - cryptonector 2y ago
    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).

cryptonector 2y ago

> - 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.).

ximm 2y ago

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

lmz 2y ago
There's a lot more code calls getXbyY vs code that calls PAM.
WhyNotHugo 2y ago
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.