The sudo & su command in Linux
sudo executes one command with elevated (usually root) privileges, after checking /etc/sudoers for permission and logging the act. su switches your whole session to another user. Modern practice: work as yourself, sudo the specific commands that need power — least privilege plus an audit trail, with your own password instead of a shared root one.
How sudo & su works
sudo is a setuid-root binary: it always runs with root privileges, and its entire job is deciding whether to use them for you. The decision walks /etc/sudoers (parsed with visudo-verified syntax), authenticates via PAM — your password, proving you are still you — and caches success per terminal for a few minutes. Every invocation is logged with user, terminal and command: the audit trail that made shared root passwords obsolete.
Before executing, sudo sanitizes: env_reset strips the environment down to a safe minimum and secure_path replaces PATH — which is why aliases vanish, why root sees different variables, and why "sudo works differently than my shell" is by design, closing an entire class of privilege-escalation tricks that rode on inherited environments.
Syntax
sudo [OPTIONS] COMMAND | su [-] [USER]Common options
| Option | What it does |
|---|---|
sudo cmd | Run one command as root (password cached ~15 min). |
sudo -u user cmd | Run as a specific user instead of root. |
sudo -i | A full root login shell — for genuinely extended admin sessions. |
sudo -l | What am I allowed to sudo here? |
sudo !! | Repeat the previous command with sudo — the classic save. |
su - user | Become another user with their full environment (the - matters). |
How to use sudo & su: examples
$ sudo systemctl restart nginxThe everyday pattern: one privileged action, then back to being yourself.
$ sudo -u postgres psqlAct as a service account without knowing its password.
$ sudo tee /etc/app.conf < local.confWrite a root-owned file: sudo must wrap the WRITER (tee), not the shell redirection.
$ sudo -lAudit your own permissions on an unfamiliar machine.
Real-world use cases for sudo & su
Least-privilege automation
A deploy user that may restart one service and nothing else: a sudoers line granting NOPASSWD for exactly "systemctl restart myapp". CI gets its power, the blast radius stays one command wide, and the audit log names every use.
Forensics from the log
Who changed the config? sudo's log (journalctl or auth.log) records user, terminal and full command for every invocation. The accountability that shared root passwords never had — and the reason auditors smile at sudo.
Pro tips and common mistakes
- Edit sudoers ONLY via visudo — it syntax-checks before saving the one file whose corruption locks everyone out.
- sudo !! after a permission-denied is the highest-value five keystrokes in the shell.
- Redirections and pipes belong to your shell, not sudo: write root files with | sudo tee, not sudo cmd > file.
Frequently asked questions about sudo & su
Why does sudo echo x > /etc/file fail?
The redirection is performed by YOUR shell, before sudo runs. Route the write through a privileged process: echo x | sudo tee /etc/file.
sudo su vs sudo -i?
Both land you in a root shell; sudo -i does it cleanly with root's login environment and is the recommended spelling.
How do I grant a user sudo?
Add them to the sudo group (Debian/Ubuntu: usermod -aG sudo name) or write a sudoers rule — always via visudo, which syntax-checks before saving a file that could lock everyone out.
Related commands
Change file permissions with numeric (755, 644) and symbolic (u+x) modes — clearly explained.
chownAssign files to users and groups — the other half of Linux permissions.
systemctlStart, stop, enable and inspect services — the control panel of modern Linux.