Use pam_rootok to Let Root Bypass a PAM Password

You will configure a PAM authentication stack that accepts UID 0 without asking for a password, while leaving non-root users to the next authentication module. The installed module is from libpam-modules version 1.5.3-5ubuntu5.7, and this guide follows its local pam_rootok(8) manual page.

Allow about fifteen minutes. You need a root shell, a backup of the PAM file you will edit, and a second login or console session for recovery. This is a security-sensitive change: a mistake in a PAM stack can lock users out or weaken an authentication boundary. Do not test an unverified edit by closing your only privileged session.

1. Confirm what pam_rootok checks

pam_rootok succeeds only when the calling user's real UID is 0. It does not check the effective UID. That distinction matters for setuid-root programs, which can retain an ordinary user's real UID while running with elevated effective authority. An elevated process is not automatically treated as root by this module.

Check your current identity before changing anything:

$ id -u
1000
$ id -ru
1000

On a root shell both commands should print 0. The second form makes the real-UID check explicit, although pam_rootok itself is a PAM module rather than a command you run directly.

Checkpoint: record whether the shell is genuinely root. If id -u is not 0, stop here and do not assume that sudo or a setuid wrapper will make this module succeed.

2. Inspect the existing service stack

PAM configuration under /etc/pam.d/ is organised by service. The local su service already contains the conventional root shortcut:

# grep -nE '^[[:space:]]*auth[[:space:]]+.*pam_(rootok|unix)\.so' /etc/pam.d/su
6:auth       sufficient pam_rootok.so
44:@include common-auth

Your line numbers and included files may differ. Read the whole relevant file, including any @include or substack entries, before changing it:

# sed -n '1,180p' /etc/pam.d/su

The configuration rule has the fields service, module type, control, module path and optional arguments. A line in /etc/pam.d/su omits the service field because the filename supplies it.

3. Back up the PAM file

Make a root-owned backup before editing. Replace the date suffix with your own clear identifier:

# cp --preserve=mode,ownership,timestamps /etc/pam.d/su /etc/pam.d/su.bak-2026-09-25
# ls -l /etc/pam.d/su /etc/pam.d/su.bak-2026-09-25

Expected output shows both files owned by root and the backup present. Keep the backup until a fresh privileged session has completed a real test. Do not copy a backup back blindly if another administrator has made a later, valid change.

4. Put pam_rootok before password authentication

For the auth phase, use sufficient before the ordinary password module:

# Root is allowed through; other users continue to password authentication.
auth  sufficient  pam_rootok.so
auth  required    pam_unix.so

The local su configuration uses this pattern before its included common stack. When pam_rootok succeeds and no earlier required module has failed, PAM returns success immediately and does not call later modules in that stack. When it fails for a non-root real UID, a sufficient failure is ignored and processing continues. Therefore, the line does not grant ordinary users access.

Do not change sufficient to required expecting the same behaviour. A required failure must ultimately fail the stack, which would reject every non-root user before the password module could authenticate them. Do not add debug casually either: the module documents it as printing debug information, and authentication diagnostics may expose more operational detail than you want in logs.

Use a configuration editor that preserves the file as plain text. The PAM line must name the module as pam_rootok.so; the module is installed at:

# test -r /lib/x86_64-linux-gnu/security/pam_rootok.so && echo 'pam_rootok module is readable'
pam_rootok module is readable

5. Check the syntax before testing access

There is no standalone syntax-check command documented by pam_rootok(8). Inspect the edited line and look for spelling, field order and accidental shell quoting:

# sed -n '1,12p' /etc/pam.d/su
# grep -nF 'auth  sufficient  pam_rootok.so' /etc/pam.d/su

The second command should print the matching line, possibly with a different line number. If the service uses an included file, verify the included target too. A successful grep proves only that text exists; it does not prove that the complete PAM stack is usable.

6. Test from a separate root session

Keep the original root session open. From a second session that is already root, run a harmless identity check through su:

# su --login --command='id -u' nobody
65534

The command should complete without a root password prompt and print the target user's numeric UID. The exact target account can vary, so substitute a non-privileged account that exists on your machine. This tests the service flow, not just the text of the configuration.

Check the root path separately without changing identity:

# su --login --command='id -u' root
0

If either test prompts unexpectedly, fails, or reports a PAM error, do not close the working root session. Inspect the service's authentication logs using the logging tools configured for your distribution, then restore the backup if the edit is the cause.

7. Recover without locking yourself out

Restoring the backup is a state-changing action and can discard later edits. Confirm the target and compare first:

# diff -u /etc/pam.d/su.bak-2026-09-25 /etc/pam.d/su
# cp --preserve=mode,ownership,timestamps /etc/pam.d/su.bak-2026-09-25 /etc/pam.d/su

Use the recovery copy only when you have confirmed that it is the correct version. Then repeat the test from the second session. If all privileged sessions are already unusable, use the provider console or rescue environment supplied by the machine owner, mount the system read-write as required by that environment, and restore the known-good PAM file there. Recovery procedures differ by host, so do not guess at device names or mount commands.