Users, Groups & sudo

Linux was designed from day one to be a multi-user system. Every process runs as a user, every file has an owner, and the kernel enforces who can access what. Understanding this model is fundamental to understanding security in Linux.

Users and UIDs

Every user has a unique numeric ID called a UID (User ID). The kernel uses UIDs internally — it doesn't care about usernames. The mapping from name to UID lives in /etc/passwd.

$ cat /etc/passwd | head -3 root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin alice:x:1000:1000:Alice Smith:/home/alice:/bin/bash # format: name:password:UID:GID:comment:home:shell
Why is the password field just "x"? Actual password hashes moved to /etc/shadow, which only root can read. The "x" means "look in shadow." This prevents regular users from seeing password hashes and running offline cracking attacks.

UID ranges by convention:

  • 0 — root (superuser, can do anything)
  • 1–999 — system accounts (daemons: www-data, mysql, nobody)
  • 1000+ — regular human users

Groups and GIDs

Groups let you share access between multiple users without making files world-readable. Each user has a primary group (set in /etc/passwd) and can belong to multiple supplementary groups.

$ cat /etc/group | grep docker docker:x:999:alice,bob # alice and bob are in the docker group # this lets them run docker commands without sudo id alice # show all groups for a user # uid=1000(alice) gid=1000(alice) groups=1000(alice),27(sudo),999(docker)

Common groups to know: sudo/wheel (admin), docker, video, audio, www-data.

The Root User

What makes root special? Root has UID 0. The kernel checks permissions differently for UID 0 — most permission checks are simply skipped. Root can read any file, kill any process, change any setting. This is why running as root is dangerous: one mistake can destroy the system.

Best practice: never log in as root directly. Use sudo for specific privileged commands.

How sudo Works

What actually happens when I run sudo? The sudo binary is SUID root — it always runs with root's UID. When you invoke it: (1) sudo checks /etc/sudoers to see if you're allowed, (2) authenticates you via PAM (your password), (3) forks a child process with root's UID, (4) runs your command.
# View your sudo permissions sudo -l # Run a single command as root sudo apt update # Run as a different user (not root) sudo -u www-data /usr/bin/php script.php # Open root shell (use sparingly) sudo -i # or: sudo su - # Edit sudoers safely (validates syntax before saving) sudo visudo

The sudoers file syntax:

# /etc/sudoers format: # user host=(runas) command alice ALL=(ALL) ALL # alice can run anything as any user bob ALL=(ALL) NOPASSWD:ALL # no password required (dangerous!) charlie ALL=(root) /usr/bin/apt # charlie can only run apt

su vs sudo

sudosu
Authenticates withYour own passwordTarget user's password
Logs to/var/log/auth.log (full audit)Less detailed
ScopeOne command at a timeFull session as target user
Best forSpecific privileged tasksSwitching to service accounts

Frequently Asked Questions

What will I learn here?

This page covers the core concepts and techniques you need to understand the topic and progress confidently to the next lesson.

How should I use this page?

Start with the overview, then follow the section links to deepen your understanding. Use the table of contents on the right to jump to specific sections.

What should I read next?

Use the navigation below to continue to the next lesson or explore related topics.