passwd and shadow

Every process on Linux runs as a numeric UID. The kernel tracks identity as a 32-bit unsigned integer — the username you see in ls -l or ps is a display convenience provided by libc’s getpwuid() lookup. The kernel cares only about the number.

# Your own UID and GID
id
# uid=1000(alice) gid=1000(alice) groups=1000(alice),27(sudo),1001(docker)

# The numeric UID of a running process
ps -o pid,uid,user,comm -p $$
# PID   UID USER     COMMAND
# 4231  1000 alice    bash

# The kernel API — syscall returns the numeric UID directly
grep -m1 '^Uid' /proc/$$/status
# Uid:    1000    1000    1000    1000
# (real  effective  saved  filesystem UIDs)

The four UID values matter when privilege escalation is involved — the effective UID is what determines what you are allowed to do right now, while the real UID records who you actually are. We will revisit this distinction when we discuss setuid binaries in the next lesson.

/etc/passwd has seven colon-delimited fields. Every user — human or system — lives in this file. It is world-readable because programs need to resolve UIDs to names.

# View a specific entry
getent passwd alice
# alice:x:1000:1000:Alice Smith,,,:/home/alice:/bin/bash
# [1]  [2][3] [4]  [5]          [6]          [7]

# Field breakdown:
# 1 — login name (alice)
# 2 — password field: 'x' means "look in /etc/shadow"; historically the actual hash was here
# 3 — UID (1000)
# 4 — primary GID (1000) — the group the process starts with
# 5 — GECOS: free-text comment, often Full Name,Office,Phone
# 6 — home directory (/home/alice)
# 7 — login shell (/bin/bash) — 'nologin' or 'false' blocks interactive login

The password field being x rather than the actual hash is the shadow split in action. Before shadow passwords (1980s Unixes), the hash lived right here — and because the file was world-readable, anyone on the system could run an offline dictionary attack. Moving hashes to a root-only file was the fix.

/etc/shadow holds the actual hash and aging policy. It is readable only by root (mode 640, owned root:shadow on Debian/Ubuntu). The format is nine colon-delimited fields.

# Only root can read shadow directly
sudo grep '^alice:' /etc/shadow
# alice:$6$rounds=5000$SaltGoesHere$LongHashValue...:19800:0:99999:7:::

# Field breakdown:
# 1 — login name (matches passwd)
# 2 — password hash in $id$[param$]salt$hash format
# 3 — last change: days since 1970-01-01 (19800 = some date)
# 4 — min days before password can be changed (0 = no minimum)
# 5 — max days before password must be changed (99999 = never)
# 6 — warning days before expiry (7 = warn 7 days ahead)
# 7 — inactive grace days after expiry before account is locked
# 8 — account expiry date (days since epoch; empty = no expiry)
# 9 — reserved

# Parse the hash algorithm from the $id$ prefix:
# $1$  = MD5 (ancient, DO NOT use)
# $5$  = SHA-256
# $6$  = SHA-512 (current Debian/Ubuntu default)
# $y$  = yescrypt (Ubuntu 22.04+, memory-hard)
# $2b$ = bcrypt (some distros)

The $id$salt$hash triple is a self-describing crypt(3) string. The algorithm ID tells the system which function to use for verification — this is why you can migrate to a stronger algorithm: new password changes produce the new format, old hashes still verify with their original algorithm until the user changes their password.

System users and human users differ by UID range and shell. The convention (configurable in /etc/login.defs) is:

# UID ranges on Debian/Ubuntu (from /etc/login.defs)
grep -E '^(UID_MIN|UID_MAX|SYS_UID_MIN|SYS_UID_MAX)' /etc/login.defs
# SYS_UID_MIN   100
# SYS_UID_MAX   999
# UID_MIN      1000
# UID_MAX     60000

# System users (UIDs 100-999) run daemons; they have no home dir or shell
getent passwd www-data
# www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin

getent passwd nobody
# nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin

# Human users start at UID 1000
getent passwd alice
# alice:x:1000:1000:Alice Smith,,,:/home/alice:/bin/bash

A system account with /usr/sbin/nologin as its shell cannot be used for interactive login — even if you somehow get a password for it, the kernel will fork the shell, but nologin immediately prints “This account is currently not available” and exits. This is the correct way to create a daemon account that should never be SSH’d into.

useradd and usermod are how you build and modify users. The key flags encode exactly the fields above.

# Create a system user for a daemon (no home dir, no login shell)
sudo useradd \
  --system \           # UID from system range (100-999)
  --no-create-home \   # don't create /home/myservice
  --shell /usr/sbin/nologin \
  --comment "MyService daemon" \
  myservice

# Verify
getent passwd myservice
# myservice:x:123:123:MyService daemon:/:/usr/sbin/nologin

# Create a human user with home dir and bash
sudo useradd \
  --create-home \
  --shell /bin/bash \
  --comment "Bob Jones" \
  bob
sudo passwd bob          # set password interactively (writes to shadow)

# Modify an existing user: add to supplementary group
sudo usermod --append --groups docker alice
# --append is CRITICAL: without it, --groups REPLACES all supplementary groups

# Lock an account (prepend ! to shadow hash — login fails, key-based SSH still works)
sudo usermod --lock bob
sudo grep '^bob:' /etc/shadow
# bob:!$6$...:...   <- the ! prefix

The --append flag on usermod -G is a classic gotcha. Without it, sudo usermod --groups docker alice would set alice’s groups to only docker, stripping her from sudo and every other group she belongs to. Always pair --groups with --append.