An overview of nsss
nsss is a secure implementation of a subset of the pwd.h, grp.h and shadow.h functionality, i.e. user authentication on Unix systems. It includes full POSIX functionality, a few GNU extensions, and an underlying C client library with better error reporting than the POSIX interface specifies.
nsss has two parts: the client library and the nsssd service.
The nsss client library
The client library provides:
- nsss-unix: a set of functions providing access to the standard /etc/passwd, /etc/group and /etc/shadow files.
- nsss-switch: a set of functions implementing the same functionality as nsss-unix, but instead of looking for information in the standard files, they connect to a nsssd service (see below) that performs the requests for them.
- three implementations of the the standard getpwnam() et al. functions: one using the nsss-unix functions, one using the nsss-switch functions, and the default one, called nsss-all, which attempts to connect to the nsssd service and retrieve information from it, but falls back to the nsss-unix implementation if it fails (for instance, if no nsssd service is listening).
Applications wishing to use nsss should be built against this client library. The getpwnam() et al. definitions will override those of the libc, and use the nsss-all, nsss-switch or nsss-unix depending on compilation options.
Unlike glibc's nsswitch, the nsss client library does not use dynamically loadable modules. nsss can be statically linked, and used in static programs. It's also quite light.
The nsssd service
For applications that need to use the nsss-all or nsss-switch implementations of getpwnam() et al. (and that is the point, otherwise the libc's implementation could generally be used over nsss-unix instead!) there needs to be a daemon running on the system, and serving requests from nsss-switch clients.
That daemon should be set up by the system administrator. It should listen to the /run/service/nsssd/s Unix domain socket; that default location can be changed at nsss build time via the --with-nsssd-socket option to the configure script.
As of 0.0.2.0, three suitable implementations of a nsssd daemon are provided by the nsss package:
- The nsssd-unix program, which is sort of a dummy implementation since it simply accesses the standard files (it simply uses the nsss-unix library). It is still useful for testing purposes, and to have a placeholder service that can easily be replaced later.
- The nsssd-nslcd program, which performs requests to a nslcd daemon running on the same system and returns the answers fetched by nslcd. This allows nsss to get its users/groups information from a LDAP database.
- The nsssd-switch program, which tries several other backends in sequence and uses the first one that succeeds.
More implementations, with a wider variety of backends, will come in future versions of nsss.
The provided programs are not meant to be run directly; instead, they use the UCSPI protocol and must be spawned by a Unix domain super-server (the equivalent of inetd, for Unix domain sockets). The s6-ipcserver program, from the s6 package, is such a super-server. What this means is that for instance, running the following command-line as root will set up a correct nsss service:
s6-ipcserver -- /run/service/nsssd/s nsssd-unix
Refinements can be added to this command-line, such as options to drop root privileges after binding to the socket, etc. Examples of how to add a nsssd service to your init scripts are provided in the examples/ subdirectory of the nsss package, for OpenRC, s6 or s6-rc based systems.