fix(pam_faillock): write deny profile to the filename that is enabled

[brennanneoh]

Correction: an earlier revision of this description claimed the typo prevented the lockout from taking effect. That was wrong, and I've corrected it below after testing it in the project's own debian13 container. The change is a naming/robustness fix, not a security fix. Apologies for the noise.

Problem

In bin/hardening.sh's pam_faillock_enabled.sh, apply() declares the profile names it intends to enable:

pam_update_profile="faillock faillock_notify"

but writes the first profile to a filename spelled with one l:

printf '%s\n' "${arr[@]}" >/usr/share/pam-configs/failock

pam-auth-update --force --enable faillock therefore names a profile that does not exist.

Actual impact (measured, not assumed)

On a default run the lockout does still take effect, for two reasons I verified in tests/docker/Dockerfile.debian13:

1. pam-auth-update --force --enable <unknown-name> exits 0 and silently ignores the unknown profile.
2. pam-auth-update enables every profile in /usr/share/pam-configs carrying Default: yes — which both generated profiles do — regardless of what --enable names.

So the misnamed file is still picked up. Measured on master:

pam-configs: capability faillock_notify failock mkhomedir systemd unix
authfail in common-auth: 1
17:auth	requisite         pam_faillock.so preauth
19:auth	[default=die] pam_faillock.so authfail

Deleting /usr/share/pam-configs/failock and re-running pam-auth-update --force drops authfail to 0, confirming it is the file, not the --enable argument, doing the work.

Why fix it anyway

The behaviour is correct today by coincidence rather than by construction:

• The --enable faillock call is a silent no-op. The loop over $pam_update_profile currently achieves nothing for that entry, which is misleading to anyone reading or maintaining this.
• It only works because both profiles are Default: yes. A profile intended to be opt-in (Default: no) would depend entirely on --enable matching the filename, and would never activate.
• It leaves a permanently misnamed failock file on every hardened host, which does not match the name in the source and is easy to mistake for cruft.
• pam-auth-update silently ignoring unknown names means this class of typo cannot surface as an error.

The change

One character: write the profile to the name that is enabled.

Verification

tests/docker_build_and_run_tests.sh debian13 pam_faillock_enabled.sh — all tests succeed, stderr empty, root/sudo consistency checks pass. shellcheck --exclude=SC2317 --shell=bash -x --source-path=SCRIPTDIR and shfmt -l -i 4 -d are both clean.

Before and after the change, common-auth ends up with both preauth and authfail lines; the difference is that /usr/share/pam-configs/faillock is now named consistently with the source and the --enable call actually refers to it.

Happy to close this if you consider it not worth the churn.

🤖 Generated with Claude Code

[brennanneoh]

Correcting myself before anyone spends review time on the original claim.

I originally described this as a security defect — that the misnamed file meant the authfail deny profile never activated. I then tested it properly in tests/docker/Dockerfile.debian13 and that is not what happens. pam-auth-update enables every Default: yes profile in /usr/share/pam-configs regardless of the --enable argument, and it exits 0 on an unknown profile name, so the misnamed failock file is applied anyway and lockout works.

I've rewritten the PR description accordingly. This is a naming/robustness fix — the --enable faillock call is a silent no-op and the generated filename doesn't match the source — not a fix for broken lockout. Reasonable to close it as not worth the churn; I'd rather have the record straight than land the change.

The other two reports I opened are unaffected by this and were verified independently: #361 and #362.