Yes /etc/passwd
is one of many ways the user account database can be stored and queried.
In many Unix-like systems, the Name Service Switch (initially from Solaris) is responsible for translating some system names to/from ids using a number of methods.
Its configuration is usually stored in /etc/nsswitch.conf
.
In there, you'll find entries for a number of databases and how they are handled (group, passwd, services, hosts, networks...). For the hosts
database which is used to translate host names to network protocol addresses, you'll find that DNS and sometimes mDNS are generally queried in addition to /etc/hosts
.
When a process requests information about a user name such as with the getpwnam()
standard function, the methods to use are looked up in that file for the passwd
entry.
If such a method is the files
method, /etc/<db>
will be looked up. On GNU systems, that's typically done by some /lib/<system>/libnss_files.so.<version>
dynamically loaded module.
But you can have many more, such as NIS+, LDAP, SQL. Some of those methods are included with the GNU libc, some can be installed separately. On Debian or derivatives, see the output of apt-cache search 'NSS module'
for instance.
In enterprise environments, where the user database is centralised, the most popular central DB was NIS, then NIS+ while these days, it's rather LDAP or Microsoft's Active Directory (or its clones for Unix).
If present, the get{pw/host/grp}...()
functions of the GNU libc will also query a name service caching daemon via /run/nscd/socket
instead of invoking the whole NSS stack and query the backend DBs directly. Then the querying will be done by nscd
and cached to speed up later queries. Some NSS modules can can also do their caching themselves.
On GNU/Linux systems, a popular method is using System Security Services (sss
). That comes with a separate daemon (sssd
) that handles the requests and despatches them to other databases (such as LDAP / AD) while also doing some caching. Then /etc/nsswitch.conf
will have a sss
method for most DBs, and the backends are configured in the sssd
configuration. PAM (responsible for authentication) also typically queries sssd
in that case.
That should help clarify why querying /etc/passwd
(or /etc/group
or /etc/hosts
...) to get account (or group/host...) information from the command line is wrong in the general case. Most modern systems will have a getent
command instead for that (also from Solaris), or more portably, you can use perl
's interface to all the standard get<db>*()
functions.
$ getent passwd bin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
$ perl -le 'print for getpwnam("bin")'
bin
x
2
2
bin
/bin
/usr/sbin/nologin
$ getent services domain
domain 53/tcp
$ perl -le 'print for getservbyname("domain", "tcp")'
domain
53
tcp
$ perl -le 'print for getservbyname("domain", "udp")'
domain
53
udp
getent passwd
instead of trying to parse the password database directly. It uses the same libc functions that the rest of the system does, so it will show you what everything else actually sees, not just what’s in the local password file.grep
can take a file name as an argument, so you never need to docat file | grep pattern
and can always just dogrep pattern file
or< file grep pattern
and similar constructs avoiding an extra command.passwd
/group
files on a bunch of systems, you maintain them in the LDAP server and configure those systems to use those servers to obtain account data. LDAP is a protocol, there are many implementations (e.g. OpenLDAP is fairly popular). Active Directory (AD) is Microsoft's.