Ensure All Files Are Owned by a User
Ensures every regular file on local filesystems is owned by a valid user account (no -nouser files).
Checked against a path’s metadata, mode, owner, group, SUID/SGID.
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
Unowned files do not directly imply a security problem, but they are generally a sign that something is amiss. They may be caused by an intruder, by an incorrect software installation or incomplete removal, or by failure to delete every file belonging to a removed account. A file with no owner becomes a hidden liability: when a new account is created and happens to reuse the orphaned UID, that account silently inherits all of those files, which can leak data or grant unintended write access. The files should be repaired and the root cause investigated.
What Pavois checks
Pavois runs find / -xdev -type f -nouser and expects empty output, meaning no file references a UID without a matching entry in /etc/passwd. The -xdev flag keeps the scan on the local filesystem (it does not cross mount points), so network mounts and pseudo-filesystems are not flagged. This is a live scan of the real inodes on disk, not a guess from a config file.
describe command("timeout 90 find / -xdev -nouser -not -path '/var/lib/private/*' -not -path '/var/cache/private/*' 2>/dev/null") do
its('exit_status') { should_not cmp 124 } # timeout killed the scan: no evidence, not a pass
its('stdout.strip') { should eq '' }
endHow to verify it is applied
Run sudo find / -xdev -type f -nouser 2>/dev/null as an administrator. Expected output: nothing (an empty result). Any path printed is an unowned file that must be fixed or removed.
Inspect & investigate
There is no daemon log for this. Audit on demand with find / -xdev -type f -nouser -ls to list offending files with their numeric UID, or find / -xdev -nouser -o -nogroup to also catch unowned groups.
Remediation
No automated harden plan is provided: an unowned file is a symptom, and blindly reassigning ownership could hide an intrusion or break an application. Investigate each file first, then either delete it or chown it to the correct account manually.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| command | find / -xdev -nouser 2>/dev/null # review each, then assign a real owner: chown <user> <file> (or remove if orphaned) |
|---|---|
| reason | an unowned file usually signals a deleted user, assign ownership deliberately, do not blindly chown |
| resource | manual |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
If left unaddressed, a future account that reuses an orphaned UID silently gains ownership of these files, potentially leaking data or granting write access. Before remediating, do not mass-chown blindly: identify why the file is unowned (recently deleted account, failed install, or compromise). Reassigning an application's data files to the wrong user can break that service; deleting files still in use can cause data loss.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R53 | direct | 2.0 | high |
| CIS | 2.2.6, 7.1.12 | direct | per OS, see the benchmark table | high |
| NIST | AC-6(1), CM-6(a) | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
| PCI DSS | 2.2.6 | 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.