/etc/passwd

The seven fields of an /etc/passwd line

The passwd(5) manual page describes one account per line:

deploy:x:1001:1001:Deploy user:/home/deploy:/bin/bash

1. name: the login name.
2. password: an encrypted password, an asterisk, or x. The letter x means the real hash is kept in the shadow file.
3. UID: the numeric user ID. The superuser, root, has UID 0.
4. GID: the numeric primary group. Extra groups are listed in /etc/group.
5. GECOS: an optional comment, usually the full name.
6. directory: the home directory, which sets HOME.
7. shell: the program run at login, which sets SHELL. An empty field means /bin/sh.

The file should be readable by all users and writable only by the superuser. An empty password field is dangerous: the manual says login is then allowed without asking for a password, although applications such as PAM can change that behaviour.

Auditing the file from the command line

Use field-aware commands instead of searching for names. Every account with UID 0 has root's privileges, as the UID 0 page explains, and the third field reveals it:

awk -F: '($3 == 0) {print $1}' /etc/passwd
awk -F: '($2 != "x") {print $1}' /etc/passwd
awk -F: '($7 !~ /(nologin|false)$/) {print $1, $7}' /etc/passwd
pwck -r

The first command should print only root. The second lists entries whose password field is not x, which deserve an explanation. The third lists accounts with a real login shell, which should match the people and automation you expect. According to the pwck(8) manual page, pwck -r runs read-only and verifies the field count, unique names, valid IDs, primary group, home directory and shell for each entry, and it exits non-zero when it finds bad entries.

Run these on a schedule and after any incident. A one-off check misses an account that appears next week, so combine it with file integrity monitoring on the file.

Service accounts, nologin shells and /etc/shadow

Daemons should run under their own accounts that cannot log in. The usual approach is a system account whose shell is nologin:

sudo useradd --system --shell /usr/sbin/nologin --home-dir /var/lib/myapp myapp

The path to nologin differs between distributions. According to nologin(8), it politely refuses a login, prints a message and exits non-zero. The useradd(8) manual adds that --system allocates a UID from the system range set in /etc/login.defs.

Hashes and ageing data live in /etc/shadow, which, per shadow(5), must not be readable by regular users. A password field starting with ! or equal to * means the account cannot log in with a password, but passwd(5) warns that such a user may still be reachable by other means such as cron or mail filters. Locking a password is therefore not the same as removing an account.

NSS, getent and the hardening checklist

The file only lists local accounts. Name lookups go through the Name Service Switch, whose order is set on the passwd: line of /etc/nsswitch.conf and which can add sources such as LDAP. To see every account the system knows, use getent, which queries those same libraries:

getent passwd
getent passwd deploy
stat -c '%a %U:%G %n' /etc/passwd /etc/shadow

According to the getent(1) manual, it exits with status 2 when a requested key is not found. The stat line confirms that /etc/passwd is root-owned and not writable by others and that /etc/shadow is not world readable.

For hardening, keep exactly one UID 0 account, give services nologin shells, remove accounts of people who left, and let sudoers rules grant privilege instead of sharing root. The least privilege guide walks through the audit, and the breach response guide tells you what to do when an unexpected entry appears.

Related terms: UID 0, sudoers, Least privilege, Root login, File integrity monitoring.