Comment by dfox
3 months 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...).
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).