All GIDs referenced in /etc/passwd must be defined in /etc/group
Ensures every primary GID referenced in /etc/passwd is actually defined in /etc/group.
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
Every primary GID assigned to a user in /etc/passwd must correspond to an existing group in /etc/group. A dangling GID is a latent privilege leak: if an administrator later creates a group with that same GID, the user silently gains access to all of its files and resources without any explicit grant.
What Pavois checks
Pavois extracts each distinct primary GID from /etc/passwd and, for each one, queries the resolved group database with getent group; any GID with no matching group is reported. The check passes only when none are dangling. Using getent consults the effective group resolution (including SSSD/LDAP), not just the flat /etc/group file.
describe command('awk -F: \'{print $4}\' /etc/passwd | sort -u | while read g; do getent group "$g" >/dev/null || echo "$g"; done') do
its('stdout.strip') { should eq '' }
endHow to verify it is applied
Run awk -F: '{print $4}' /etc/passwd | sort -u | while read g; do getent group "$g" >/dev/null || echo "$g"; done. Expected output: nothing. Any printed GID is referenced by a user but undefined as a group.
Inspect & investigate
- Find which users reference an orphan GID:
awk -F: -v g=<gid> '$4==g{print $1}' /etc/passwd. - Inspect group definitions:
getent grouporcat /etc/group. - Integrity check:
grpckandpwck.
Remediation
No automated remediation is shipped. Fix it manually: either create the missing group (groupadd -g <gid> <name>) or reassign the affected users to a valid group (usermod -g <validgid> <user>), then re-run the scan.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| command | awk -F: '{print $4}' /etc/passwd | sort -u | while read g; do getent group "$g" >/dev/null || echo "missing group gid=$g"; done # groupadd -g <gid> <name> for each, or reassign the user's primary group |
|---|---|
| reason | a user's primary GID must exist in /etc/group, create the missing group deliberately |
| resource | manual |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Misconfiguration is low-severity today but becomes a privilege leak the day a group is created with a previously dangling GID. Before fixing, identify which users hold the orphan GID and decide deliberately whether the group should exist or the users should move; reassigning a user's primary group changes default ownership of files they create afterwards.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 7.2.3, 8.2.2 | direct | per OS, see the benchmark table | high |
| NIST | CM-6(a), IA-2 | supporting | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | medium |
| PCI DSS | 8.2.2 | 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.