Ensure All Accounts on the System Have Unique User IDs
Verifies that no two accounts in /etc/passwd share the same numeric UID.
Checked against what is installed or registered, packages present/absent, account databases.
A mapping is a cross-reference to where each standard places this requirement, anchored and cross-validated, not a claim of equivalence. A passing check is evidence toward these references, how to read it.
Why this rule matters
When two accounts share a UID, the kernel treats them as the same identity: they have identical file ownership and permissions, and audit records cannot distinguish who performed an action. This destroys individual accountability and lets one account read or modify another's files. Two accounts with UID 0 means two unaudited roots.
What Pavois checks
Pavois runs an awk pass over /etc/passwd and flags any UID that appears more than once; the expected output is empty. /etc/passwd is the authoritative local account database the kernel and PAM resolve against, so reading it directly reflects the effective set of accounts (local accounts; directory-backed identities via SSSD/LDAP are out of scope here).
describe command('awk -F: \'($3 in s){print $3}{s[$3]}\' /etc/passwd') do
its('stdout.strip') { should eq '' }
endHow to verify it is applied
Run awk -F: '{print $3}' /etc/passwd | sort | uniq -d. The expected output is empty (no duplicate UID). Any line printed is a UID shared by multiple accounts.
Inspect & investigate
Account creation/modification is logged by useradd/usermod in /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL). To audit the database, getent passwd | awk -F: '{print $3}' | sort | uniq -d lists any duplicated UID.
Remediation
No automated harden plan ships for this rule, it must be fixed manually and carefully, because changing a UID re-homes file ownership. Identify the duplicate with the verify command, decide which account keeps the UID, assign the other a free UID with usermod -u <newuid> <user>, then run find / -uid <olduid> -exec chown <newuid> {} + to repair ownership of its files.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| command | cut -d: -f3 /etc/passwd | sort | uniq -d # duplicate UIDs # resolve by usermod -u <new-uid> <user> (and chown their files), manual |
|---|---|
| reason | duplicate UIDs need a deliberate renumber/merge, never auto-change a UID |
| resource | manual |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Reassigning a UID is the disruptive part, not the audit: every file owned by the old UID becomes orphaned until you chown it, which can break services, home directories, cron jobs and mail spools. Do this during a maintenance window, ensure the user is logged out, and inventory their files first (find / -uid <olduid>). The detection step itself is read-only and harmless.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 7.2.5, 8.2.1, 7.2.4 | direct | per OS, see the benchmark table | high |
| PCI DSS | 8.2.1 | supporting | 4.0.1 | medium |
Each reference is a cross-reference anchored in the upstream benchmark and cross-validated against the SCAP Security Guide and ansible-lockdown, not a claim of equivalence. Direct = a prescriptive, line-level requirement; supporting = an abstract control family (NIST) the check provides evidence toward. How to read a mapping.