Users & Groups

What Are Users and Groups?

Every process and file on Linux is owned by a user ID (UID) and a group ID (GID) — numbers, not names. Usernames are just a human-friendly mapping stored in /etc/passwd; the kernel only cares about the numeric IDs.

flowchart LR U[Username: 'deploy'] -->|mapped via /etc/passwd| UID["UID: 1001"] UID --> PROC[Every process it runs] UID --> FILES[Every file it owns] G[Group: 'developers'] -->|mapped via /etc/group| GID["GID: 2001"]

Key Files

cat /etc/passwd
# deploy:x:1001:1001:Deploy User:/home/deploy:/bin/bash
#  ^name ^x  ^UID ^GID  ^comment    ^home       ^shell

cat /etc/group
# developers:x:2001:deploy,alice

cat /etc/shadow   # hashed passwords + aging policy (root-readable only)

The x in the password field of /etc/passwd means the real hash lives in /etc/shadow, which is unreadable by normal users — this two-file split exists purely for security (/etc/passwd must stay world-readable for tools like ls -l to map UIDs to names).

UID 0 Is Root — Always

id                 # shows your UID, GID, and all group memberships
id deploy
whoami
sudo whoami        # runs as UID 0 temporarily

su - otheruser     # switch user, loading their environment

There’s nothing magic about the name “root” — any account with UID 0 has full root privileges, which is why auditing /etc/passwd for unexpected UID 0 entries is a real security check.

Primary vs Supplementary Groups

Primary group: the GID listed in /etc/passwd — the default group for files a user creates.
Supplementary groups: additional groups (e.g., docker, sudo, developers) granting extra permissions without changing the primary one.

groups deploy                     # all groups deploy belongs to
sudo usermod -aG docker deploy    # add deploy to the 'docker' group (supplementary)
newgrp docker                     # activate a group membership in current shell without re-login

Adding a user to the docker group is effectively root-equivalent — anyone in that group can mount the host filesystem via a container.

User Management Commands

sudo useradd -m -s /bin/bash deploy    # create user with home dir + shell
sudo passwd deploy                     # set password
sudo userdel -r deploy                 # delete user + home directory
sudo groupadd developers
sudo usermod -aG developers deploy

sudo vs su

	`sudo`	`su`
Runs as	Specified user (default: root), per-command	Full login shell as target user
Password	Your own (if configured)	Target user’s password
Auditing	Logged per-command (`/var/log/auth.log`)	Less granular
Config	`/etc/sudoers` (edit via `visudo`)	N/A

Production Considerations

Never edit /etc/sudoers directly — always use visudo, which validates syntax before saving (a broken sudoers file can lock out all sudo access).
Service accounts (nginx, postgres) should have no login shell (/usr/sbin/nologin) and no password — they exist only to own processes/files, not to be logged into.
Periodically audit /etc/passwd for stray UID 0 accounts and /etc/group for unexpected members of sudo/docker/wheel.

Quick Interview Answer

“Linux identity is numeric — UID and GID — with /etc/passwd and /etc/group mapping those to human-readable names, and /etc/shadow holding password hashes separately for security. Any account with UID 0 is root, regardless of its name. sudo runs a single command as another user with per-command auditing; su opens a full login shell as that user.”

Common Mistakes

Editing /etc/sudoers with a plain text editor instead of visudo, risking a syntax error that locks out sudo entirely.
Not realizing adding a user to the docker group is equivalent to giving them root.
Giving service accounts an interactive shell and a real password instead of /usr/sbin/nologin.