Users, Groups, and sudo
Linux's security model is built around users and groups: every process runs as some user, every file is owned by a user and a group, and access decisions come down to comparing a process's identity against a file's owner/group/permissions. Beyond regular human user accounts, Linux also has system/service accounts (like www-data or postgres) that run daemons with only the privileges they need, and one special account — root (UID 0) — that bypasses nearly all permission checks. Because working as root directly is risky (any mistake or compromised command runs with full system power), modern Linux practice favors sudo, which lets an authorized regular user run specific commands with elevated privileges temporarily and with an audit trail, rather than logging in as root outright.
Cricket analogy: Every player's access to the dressing room and kit depends on their registered team and role, much like Linux checks a process's user and group against a file's permissions; the ground curator (root) can enter anywhere, but captains preferred requesting temporary access via ground staff rather than holding master keys themselves.
Users and groups: creating and managing
Each user has a UID (numeric user ID), a primary group (GID), and can additionally belong to any number of secondary/supplementary groups. Primary group membership determines the group ownership of files a user creates by default, while supplementary groups grant additional access without changing that default — e.g. adding a user to the docker or sudo group grants specific extra capabilities. useradd/adduser create accounts, usermod modifies them (including group membership), and groupadd creates new groups. On Debian/Ubuntu, adduser is a friendlier interactive wrapper around the lower-level useradd.
Cricket analogy: A player has one home franchise (primary group, like Mumbai Indians) determining their default jersey, but can also be added to a national squad (secondary group) for extra privileges; selectors use registration forms (useradd) and roster updates (usermod) to add players to squads.
# Create a new user with a home directory (Debian/Ubuntu-friendly interactive version)
sudo adduser jsmith
# Equivalent lower-level useradd, explicit flags (works on both Debian and RHEL families)
sudo useradd -m -s /bin/bash -c "Jane Smith" jsmith
sudo passwd jsmith # set the password interactively
# Add an existing user to the sudo group (Debian/Ubuntu) or wheel group (RHEL/CentOS)
sudo usermod -aG sudo jsmith # Debian/Ubuntu
sudo usermod -aG wheel jsmith # RHEL/CentOS/Fedora
# List which groups a user belongs to
groups jsmith
id jsmith
# Create a new group and add multiple existing users to it
sudo groupadd webapps
sudo usermod -aG webapps jsmith
sudo usermod -aG webapps alicesudo: controlled privilege escalation
sudo ('substitute user do', historically 'superuser do') lets a permitted user run a command as another user — almost always root — after authenticating with their own password (not root's), and it logs every invocation (typically to /var/log/auth.log on Debian/Ubuntu or /var/log/secure on RHEL) for accountability. Who is allowed to run what is defined in /etc/sudoers and files under /etc/sudoers.d/, which should always be edited with visudo rather than a plain text editor, because visudo validates the syntax before saving and prevents a broken sudoers file from locking every admin out of privilege escalation.
Cricket analogy: When a vice-captain calls for a DRS review, it's logged under their own name, not the captain's, so officials can audit every decision; who may call for review is written in the team charter, and any edit to that charter is checked by the match referee before saving, preventing a broken rule from locking out the whole team.
# Run a single command as root
sudo systemctl restart nginx
# Open a root shell (use sparingly; prefer targeted sudo commands over full shells)
sudo -i
# Run a command as a different, non-root user
sudo -u postgres psql
# Safely edit the sudoers policy (validates syntax before saving)
sudo visudo
# Example sudoers line granting passwordless restarts of one service only
# (add via visudo, in /etc/sudoers.d/nginx-restart)
# jsmith ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx
# Check what a user is allowed to run
sudo -l -U jsmithOn RHEL/CentOS/Fedora, the traditional 'admin' group for sudo access is called wheel rather than sudo (a naming convention going back decades to early Unix). Ubuntu and Debian instead use a group literally named sudo. Functionally they serve the same purpose — check /etc/sudoers (via visudo) or /etc/sudoers.d/ for the exact %wheel or %sudo group entry granting ALL=(ALL:ALL) ALL to see which is active on a given system.
Never edit /etc/sudoers directly with a plain editor like nano or vim — a syntax error saved directly to that file can break sudo entirely for every user on the system, sometimes requiring single-user/rescue mode to fix. Always use sudo visudo, which edits a temporary copy and validates its syntax before atomically replacing the real file, refusing to save if there's an error.
- Every user has a UID, a primary group (GID), and optional supplementary groups;
idandgroupsshow a user's memberships. - useradd/adduser create users, usermod -aG modifies group membership (always use -aG to append, not -G alone, which replaces all groups).
- root (UID 0) bypasses almost all permission checks; sudo lets specific users run specific commands with elevated privileges without logging in as root.
- /etc/sudoers and /etc/sudoers.d/ define sudo policy and must always be edited with visudo, which validates syntax before saving.
- Debian/Ubuntu use the 'sudo' group for admin access; RHEL/CentOS/Fedora traditionally use 'wheel' for the same purpose.
- sudo actions are logged (e.g. to /var/log/auth.log or /var/log/secure) for auditability, unlike working as root directly.
Practice what you learned
1. What is the risk of running `usermod -G newgroup username` instead of `usermod -aG newgroup username`?
2. Why should /etc/sudoers always be edited with visudo instead of a regular text editor?
3. On RHEL/CentOS/Fedora systems, which group traditionally grants sudo/administrative access, analogous to Ubuntu's 'sudo' group?
4. What does `sudo -u postgres psql` do?
5. Which command shows both the UID and all group memberships (primary and supplementary) for a user in one output?
Was this page helpful?
You May Also Like
File Permissions Explained (rwx)
Understand the Linux permission model — read, write, and execute bits for owner, group, and others — and how ls -l output maps to those permissions.
chmod and chown
Learn how to change file permissions with chmod (symbolic and octal modes) and change ownership with chown and chgrp, including recursive usage and special bits.
The /etc/passwd and /etc/shadow Files
Understand the structure and purpose of /etc/passwd (user account metadata) and /etc/shadow (hashed passwords and aging policy), and how they work together.
SSH and Remote Access
Understand SSH's client-server model, key-based authentication, port forwarding, and configuration practices for securely administering remote Linux systems.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsDocker & Kubernetes Study Notes
YAML · 40 topics