sudo and the Superuser

Every Linux system has one account that can do anything: read any file, kill any process, install software, and reconfigure the kernel itself. That account is called root, or the superuser. Because root is so powerful, modern distributions discourage logging in as root directly and instead give trusted users the ability to run individual commands as root through a tool called sudo. Understanding the difference between being root and using sudo is one of the most important safety habits you can build as a Linux user.

Overview / How it works

On Linux, every process runs with a user ID (UID) that the kernel uses to decide what that process is allowed to do. The user with UID 0 is root, and the kernel treats UID 0 specially: file permission checks, the ability to bind to low-numbered network ports, the ability to change ownership of files, load kernel modules, and mount filesystems are all gated on “is your UID 0?” Historically, administrators would log in directly as root (or run su - to become root) whenever they needed to do privileged work, and stay root until they were done. This is risky for two reasons: a single mistyped command run as root has no safety net (there’s no permission check to stop rm -rf in the wrong directory), and there’s no record of which human was root at any given moment if multiple administrators share the password.

sudo (“superuser do”) solves both problems. Instead of switching your whole shell session to root, you prefix a single command with sudo. The sudo program checks a configuration file, /etc/sudoers, to see whether your user is allowed to run that command as root (or as another user). If allowed, it asks for your own account password (not root’s — root usually has no usable password at all on modern distros), runs the one command with root privileges, logs the action to the system log, and then your shell returns to running as your normal, unprivileged self. You stay you; only that one command briefly becomes root.

Two ideas make this practical. First, group membership: on Debian/Ubuntu, being in the sudo group is what grants sudo access (RHEL/Fedora use a group called wheel for the same purpose). Second, password caching: after you authenticate once, sudo remembers it for a short window (15 minutes by default) so you aren’t typing your password before every single command in a string of related admin tasks.

Syntax

sudo [options] command [arguments]
Option Meaning
-u user Run the command as user instead of root (e.g. sudo -u www-data whoami).
-i Start an interactive root login shell (reads root’s own profile/environment). Use sparingly.
-s Start a root shell using your current environment instead of root’s.
-l List the commands your account is permitted to run with sudo.
-k Forget the cached password immediately (next sudo asks again).
-v Refresh/extend the cached-password timer without running a command.
-e Edit a file as root safely (equivalent to sudoedit).

Examples

Example 1: Installing a package

sudo apt update && sudo apt install -y nginx
[sudo] password for maria: 
Hit:1 http://archive.ubuntu.com/ubuntu jammy InRelease
Reading package lists... Done
...
Setting up nginx (1.18.0-6ubuntu14.4) ...

The first sudo in the chain prompts for your password. Because sudo caches that authentication for a few minutes, the second sudo apt install in the same command usually runs without asking again.

Example 2: Running a command as a different, non-root user

sudo -u deploy /usr/bin/php artisan queue:restart
Broadcasting restart signal...

This runs the command as the deploy service account rather than as root — useful when a web application’s files are owned by a dedicated user and you need to act on its behalf without giving that account a login password.

Example 3: Checking what you’re allowed to do

sudo -l
User maria may run the following commands on web01:
    (ALL : ALL) ALL

(ALL : ALL) ALL means this user can run any command, as any user, on this host. On a more locked-down server this might instead list only a handful of specific commands, such as /usr/bin/systemctl restart nginx.

Example 4: Editing the sudoers file safely

sudo visudo

This opens /etc/sudoers in a text editor, but crucially, visudo checks the file’s syntax before saving. If the syntax is broken, it refuses to save and warns you — protecting you from locking every user, including yourself, out of sudo with a typo. Never edit /etc/sudoers directly with a plain editor.

How it works step by step

  1. You run sudo some-command. The sudo binary itself is owned by root and has the setuid bit set, which lets it briefly acquire root privileges even though you launched it as yourself.
  2. sudo looks up your username (and its group memberships) in /etc/sudoers (and any files under /etc/sudoers.d/) to check whether a matching rule allows you to run that command as the target user.
  3. If no cached, still-valid authentication exists, sudo prompts for your password and verifies it via PAM (the same mechanism used for login).
  4. If authorized, sudo forks a child process, sets its UID (and GID) to root’s (UID 0), and execs your command in that child. The kernel now applies root’s permission rules to everything that process does.
  5. The action — who ran what, as whom, when — is written to the system log (typically /var/log/auth.log on Debian/Ubuntu, viewable with journalctl), creating an audit trail.
  6. When the command finishes, the child process exits. Your original shell was never root; it simply continues as your normal user.

Common Mistakes

Mistake 1: Running an entire script or shell as root “just in case”

sudo su -
# ...now everything you type for the rest of the session runs as root...

Staying in a root shell defeats sudo’s whole purpose: no per-command confirmation, no granular audit trail, and one mistyped path can destroy the system. Prefer running the single privileged command you actually need:

sudo systemctl restart nginx

Mistake 2: Piping a downloaded script straight into sudo

curl -fsSL "https://example.com/install.sh" | sudo bash

This executes an entire remote script with root privileges without ever reading it, trusting the network connection and the remote server completely. Download it, inspect it, then run it:

curl -fsSL "https://example.com/install.sh" -o install.sh
less install.sh
sudo bash install.sh

Mistake 3: Using sudo with shell redirection and expecting it to work

sudo echo "127.0.0.1 internal.example.com" >> /etc/hosts

This fails with a permission error on /etc/hosts even though sudo is present, because the redirection (>>) is set up by your unprivileged shell before sudo ever runs — only echo itself becomes root, not the redirect target. Use tee (which does the writing as root) instead:

echo "127.0.0.1 internal.example.com" | sudo tee -a /etc/hosts

Mistake 4: Editing /etc/sudoers with a plain editor

sudo nano /etc/sudoers

A single syntax mistake here can break sudo for every account on the machine, sometimes requiring single-user/recovery mode to fix. Always use visudo, which validates syntax before writing:

sudo visudo

Best Practices

  • Prefer sudo <command> for a single action over sudo su - or logging in as root for a whole session.
  • Always edit /etc/sudoers with sudo visudo, never a plain text editor.
  • Grant sudo access by adding a user to the sudo group (Debian/Ubuntu) or wheel group (RHEL/Fedora) rather than editing sudoers by hand for every user.
  • For fine-grained access, add a dedicated file under /etc/sudoers.d/ (e.g. /etc/sudoers.d/deploy-user) instead of editing the main file, so rules are easy to review and remove.
  • Use NOPASSWD: sudoers entries sparingly — only for narrow, low-risk automation commands, never for ALL.
  • Run sudo -k before stepping away from a shared or unattended terminal to clear the cached authentication immediately.
  • Check /var/log/auth.log (or journalctl _COMM=sudo) periodically on servers to review who has used sudo and for what.
  • Never disable root’s password entirely and also disable sudo — make sure there is always at least one working path to regain administrative access.

Practice Exercises

  1. Check whether your own account has sudo access, and if so, list exactly which commands it’s permitted to run.
  2. Create a new file at /etc/sudoers.d/backup-check (using visudo -f to edit it safely) that would allow a hypothetical backup user to run /usr/bin/systemctl status backup.service without a password. Don’t apply it to a real user unless you understand the security implications — just get the syntax right.
  3. Append a line to /etc/hosts using sudo correctly (hint: plain sudo echo ... >> file will not work — figure out why and use the correct command).

Summary

  • Root (UID 0) is the Linux superuser, exempt from normal permission checks by the kernel.
  • sudo lets an authorized user run individual commands as root (or another user) using their own password, instead of logging in as root for an entire session.
  • Sudo access is controlled by /etc/sudoers and files in /etc/sudoers.d/, and is typically granted via the sudo (Debian/Ubuntu) or wheel (RHEL/Fedora) group.
  • Always edit sudoers configuration with visudo, which validates syntax before saving.
  • Redirection (>, >>) happens in your unprivileged shell even under sudo — use sudo tee to write to root-owned files.
  • Every sudo invocation is logged, giving an audit trail that a shared root login cannot.