Use pam_permit Safely in a PAM Stack

You will finish able to identify what pam_permit does, inspect where it is used, and judge whether its result is safe in the surrounding PAM stack. The key fact is simple: this module always returns PAM_SUCCESS. It does not authenticate a person, check an account, change a password or create a session policy.

Allow about fifteen minutes. You need a shell on a Linux system using Linux-PAM and permission to read the relevant files under /etc/pam.d. The examples use the installed Ubuntu package libpam-modules version 1.5.3-5ubuntu5.7. Reading the configuration is unprivileged. Editing a PAM file requires root and can lock you out, so this guide does not ask you to make that change.

1. Confirm the installed module

Start with a read-only check. This confirms both the package version and the shared object that PAM loads:

$ dpkg-query -W -f='${Package} ${Version}\n' libpam-modules:amd64
libpam-modules 1.5.3-5ubuntu5.7
$ test -r /usr/lib/x86_64-linux-gnu/security/pam_permit.so && printf '%s\n' 'module present'
module present

The library path can differ on another architecture or distribution. Use the path reported by the package manager rather than copying this pathname into a configuration file.

2. Read the module contract

Ask the local manual page for the authoritative interface:

$ man 8 pam_permit

There are no module options. The module types provided are auth, account, password and session. In each case the module returns PAM_SUCCESS. In an authentication request, if the application has not supplied a user name, the module sets it to nobody. That fallback exists because an unknown name can confuse applications and other PAM modules; it is not an account lookup.

Do not read 'always succeeds' as 'the whole PAM operation always succeeds'. PAM evaluates a stack of modules. The control flag, the result of other modules and the service's PAM configuration still matter. A required failure elsewhere can make the overall operation fail even when pam_permit succeeds.

3. Find every active reference

Search the PAM service files without changing them. The command may need sudo on a host whose files are not world-readable:

$ rg -n --hidden --glob '!*.dpkg-*' 'pam_permit\.so' /etc/pam.d /etc/pam.conf 2>/dev/null
/etc/pam.d/example-service:12:account required pam_permit.so

The displayed service name is only an example. Your output may be empty, or it may contain several services. Also check included files: a line in one service can pull in a common stack from a file such as common-auth. Read the complete service configuration before deciding what a line permits.

Some distributions manage PAM snippets through a configuration tool. That tool may regenerate files, so do not edit a generated fragment without first establishing its owner. On this host, pam-auth-update is installed, but its presence does not mean that every pam_permit reference is safe to change through it.

4. Understand the dangerous placement

The manual page gives this representative line:

account required pam_permit.so

Placed in an account stack, it lets that module contribute success to account management. It does not check whether the account is expired, locked, authorised for the service or subject to access restrictions. If other account modules are absent or bypassed, the service can accept an account that should have been rejected.

The same risk applies in other stack types. An auth line is not a password check. A password line is not a password-change policy. A session line is not a safe session setup. The module supplies success and does nothing else.

5. Treat control flags as part of the behaviour

In a PAM configuration, the word between the module type and module name is a control flag. It changes how this module's result combines with other results. For example, required records failure while allowing the stack to continue, whereas sufficient can allow an early success when no earlier required module has failed. The exact result still depends on the rest of the stack and any bracketed control syntax.

For that reason, this isolated test is not a valid safety check:

auth required pam_permit.so

It proves only that one module returned success. It says nothing about whether a password, certificate, access rule or account expiry was checked elsewhere. Evaluate the complete service stack and test the real operation with a non-privileged test account before changing policy.

6. Recover from an unsafe change

Before any root edit, save the original file and record the service you are changing. If a new pam_permit.so line causes unexpected access, restore the original file from that backup and test from the existing console or administrative session. Do not close your last working root session until the PAM operation has been tested.

If a package or configuration manager owns the line, revert through that manager or reinstall the owning configuration package according to local policy. Avoid deleting an entire PAM file to remove one line: that can remove unrelated authentication, account or session rules and make recovery harder.