Ensure All Groups on the System Have Unique Group ID
Ensures every group on the system has a distinct GID, so no two groups collide into one identity.
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
The kernel enforces permissions by GID, not by group name. If two group entries share the same GID, the system treats them as the same group: a file group-owned by one is accessible to the members of the other, and audit trails can no longer attribute access to a single group. Unique GIDs are what make group-based access control and accountability meaningful.
What Pavois checks
Pavois reads all resolved group entries and flags any GID that appears more than once. Looking at the effective group database (as exposed by the system) rather than trusting a single file ensures duplicates introduced through NSS sources are also detected.
describe command('awk -F: \'($3 in s){print $3}{s[$3]}\' /etc/group') do
its('stdout.strip') { should eq '' }
endHow to verify it is applied
List any duplicated GID:
awk -F: '($3 in s){print $3}{s[$3]}' /etc/group, expected output is empty.getent group | cut -d: -f3 | sort | uniq -d, expected to print nothing (no repeated GID).
Inspect & investigate
Group changes are visible in user-management logs:
grep -E 'groupadd|groupmod' /var/log/auth.log(Debian/Ubuntu) //var/log/secure(RHEL), shows when groups were created or renumbered.getent groupprovides the authoritative current GID map.
Remediation
No automated harden plan is defined for this rule yet, so it must be applied manually: pick one of each colliding pair and give it a free GID with groupmod -g <newgid> <group>, then re-own its files (find / -xdev -gid <oldgid> -exec chgrp <group> {} +). Choose which group to renumber based on which has the fewest owned files.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| command | cut -d: -f3 /etc/group | sort | uniq -d # groupmod -g <new-gid> <group> (and fix file groups), manual |
|---|---|
| reason | duplicate GIDs need a deliberate renumber, never auto-change a GID |
| resource | manual |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Risk if not applied: two groups sharing a GID silently merge their access rights and destroy per-group accountability.
Precautions before applying: before groupmod, inventory the files owned by the old GID so you can re-chgrp them; otherwise they become orphaned or fall under the surviving group. Avoid renumbering system groups that packages or services hard-code; prefer renumbering the locally created group. Apply during a maintenance window and verify affected services after the change.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 7.2.6, 8.2.1, 7.2.5 | 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.