NSS is the "Name Service Switch"; it allows the standard C library to support pluggable sources of naming information. In the bad old days, everything was hard-coded to use /etc/passwd to find users. This meant that the Athena login process had to look up a user in Hesiod and add their passwd entry to that file when they logged in (and usually remove it when they logged out). Now all we need to do is to install the libnss-hesiod package, and configure /etc/nsswitch.conf (and /etc/hesiod.conf) appropriately, and everything works: all users are automatically available to the system without having to touch /etc/passwd.

Of course this depends on applications having the foresight to use the standard C library functions for reading passwd entries, but most of them do; even in the bad old days, calling getpwnam was easier than reading /etc/passwd by hand.

As compared with PAM, NSS provides identity information. PAM builds on that to do authentication and then authorization. In other words, NSS is what makes accounts exist on your machine, and PAM controls who can log in to them.

Types of name service data

NSS supports the following useful types of data, among others:

  • passwd: usernames, UIDs, real names, shells, and home directories, e.g.,
    sipb0:*:12156:65534:Guest0 Sipb,,,,:/mit/sipb0:/bin/athena/tcsh
  • group: group names and membership, e.g.,
  • hosts: hostnames and addresses, e.g.,
  • services: service names and port numbers, e.g.,
    ircd                  6667/tcp

See nsswitch.conf(5) for a complete list. All of these are traditionally configured by a file in /etc of the same name.

NSS services

If you just want to use /etc/foo for the foo service, then you can use the "files" service, provided by /lib/ There are some other backends, including "nis" for NIS/NIS+/YP, and "db" if you carry around local config big enough to be worth compressing in a Berkeley DB.

The NSS backend we use most is "hesiod", which supports lookups for all of the data that you can keep in Hesiod. One thing it does not support is enumerating all the data; you can't read through all of Hesiod the way you can just read all of a file.

The other useful backend is "dns", which supports the "hosts" key type.

One other extremely important backend is "nonlocal", which the Debathena project developed. This is a backend that will lookup a data type with certain restrictions intended to keep your system safe from less-trusted name service data sources. For instance, a user in a nonlocal data source cannot claim to be in a local group. This is very important for us because DNS (which powers Hesiod) is easy to spoof; even if it weren't, you might not want to trust that there's no bug in the Athena server software that generates this data. See NssNonlocal for more information.

Another useful backend is "afspag", which is only valid for the "group" type. Since AFS pags (process authentication groups) are represented as normal groups in your supplementary group list, this gives them vaguely useful names so that it doesn't look like you're in nonexistent groups.


All together, a basic nsswitch.conf for Athena would look something like

passwd: files hesiod
group:  files hesiod afspag
hosts:   files dns
services: files
networks: files

In practice, because of NssNonlocal, it looks more like

passwd: files nonlocal
passwd_nonlocal: hesiod


Looking things up in NSS

From the command line, you can use the getent program to perform a query, e.g.,

dr-wily:~ geofft$ getent passwd root

Note that this entry, from /etc/passwd, is overriding the slightly different entry for root in Hesiod:

dr-wily:~ geofft$ hesinfo root passwd
root:*:0:101:Wizard A Root,,,,:/mit/root:/bin/csh

Also note that the argument order is backwards between getent and hesinfo.

As a programmer, NSS is what provides most of the functions starting with "get" in the C library, e.g., getpwnam, getpwuid, getgrnam, gethostbyname, getservbyport, etc. etc.