UIDs, GIDs, and supplementary groups · Linux

When a process opens a file, the kernel does not check “is the user called alice allowed?”. It checks “is the user’s UID in the file’s ACL?”. The names are for humans; the numbers are for the kernel.

UID and GID

Every process on the system has:

Attribute	Meaning
Real UID	The UID of the user who started the process
Effective UID	The UID the kernel uses for permission checks (after setuid/setgid transitions)
Saved set-UID	The UID a setuid binary can revert to
Filesystem UID	Used by NFS for permission checks (usually equals effective UID)
Real GID	Primary GID of the user who started the process
Effective GID	GID used for permission checks
Supplementary groups	Additional GIDs the process is a member of

Read-only / Safeid— id shows real UID, real GID, and all supplementary groups. The numbers are what the kernel sees; the names are resolved via NSS.

$ id

uid=1000(alice) gid=1000(alice) groups=1000(alice),4(adm),27(sudo),100(users)

Illustrative output

Read-only / Safeid for another user— id USERNAME shows another user's identity, if the calling user has permission to read it (root can always; non-root usually can for users in the same NSS source).

$ id www-data

uid=33(www-data) gid=33(www-data) groups=33(www-data)

Illustrative output

Primary vs supplementary

A user has one primary group (the GID in /etc/passwd) and zero or more supplementary groups (the comma-separated list in /etc/group, plus groups managed by LDAP/SSSD).

The kernel checks supplementary groups when evaluating file permissions — if a file is group-readable and the user’s primary GID does not match the file’s group, the kernel checks every supplementary group.

Read-only / Safeeffective access via supplementary group— alice can read /var/log/syslog because her supplementary group 4 (adm) matches the file's group, even though her primary GID is 1000.

$ stat -c '%U %G %a %n' /var/log/syslog; id -G alice

root adm 0640 /var/log/syslog
1000 4 27 100

Illustrative output

Adding users to supplementary groups

Configuration changeusermod -aG— -aG APPENDS to the supplementary groups. Without -a, -G REPLACES the supplementary groups — a classic production bug. Always -aG.

$ sudo usermod -aG docker alice; id alice; groups alice

uid=1000(alice) gid=1000(alice) groups=1000(alice),4(adm),27(sudo),100(users),999(docker)
alice adm sudo users docker

Illustrative output

Configuration changegpasswd— gpasswd -a USER GROUP appends USER to GROUP, the safe equivalent of usermod -aG. getent group reads the current member list, which you need before ever using the -M form below. gpasswd also sets a group password and designates group administrators.

$ sudo gpasswd -a alice docker; getent group admins

Illustrative output

`gpasswd -M` is to groups what `usermod -G` is to users

gpasswd -M alice,bob admins does not add alice and bob. It replaces the entire member list with exactly those two names. Everyone else is removed, with no confirmation and no output.

That is the same failure as usermod -G above, moved one level up. It is worse in one respect: usermod -G locks out one user, while a group that backs a sudoers rule or an SSH AllowGroups directive can lock out every administrator on the host at once.

If you need -M — and you rarely do — read the current list first and build the new one from it:

getent group admins
#   admins:x:1004:alice,bob,carol

sudo gpasswd -M "$(getent group admins | cut -d: -f4),dave" admins
getent group admins        # confirm carol and bob are still there

To add a single member, gpasswd -a dave admins is the correct command and cannot remove anybody.

Common group conventions

Group	Purpose
`root`	UID 0
`wheel` (RHEL-family) or `sudo` (Debian-family)	Members may use `sudo`
`adm`	Members may read logs in /var/log
`users`	All human users (sometimes)
`docker`	Members may use the Docker socket without sudo
`kvm`	Members may use /dev/kvm
`systemd-journal`	Members may read the system journal

**Always use -aG or gpasswd -a.** Never usermod -G without -a
Audit sudo/sudoers groups quarterly. Membership should be intentional and reviewed
Prefer group membership over per-file ACLs. Group membership scales; per-file ACLs sprawl
Document custom groups. A group called "deploy" is meaningful; a group called "g1234" is not

The effective UID and root

A process running as root has effective UID 0. The kernel treats UID 0 as “may do anything” subject to capability checks, LSM checks (SELinux, AppArmor), and seccomp filters. The difference between “process has UID 0” and “process has CAP_NET_BIND_SERVICE but otherwise is unprivileged” is the difference between a service that owns the entire machine and one that can only bind to a port.

What `newgrp` does

Configuration changenewgrp— newgrp changes the current shell's primary GID to the named group, prompting for a password if the group is protected. Useful for occasional access to a group without logging out and back in. Rare in production automation.

$ newgrp docker; id

uid=1000(alice) gid=1000(alice) groups=1000(alice),4(adm),27(sudo),100(users),999(docker)

Illustrative output

UID and GID

Primary vs supplementary

Adding users to supplementary groups

Common group conventions

The effective UID and root

What newgrp does

Knowledge check

What `newgrp` does