Skip to content

Privilege Escalation

You’ve typed sudo dozens of times across the last two sections without a real explanation of what it’s actually doing. This chapter closes that gap — what sudo and su each do differently, why one is generally the safer default, and where the rules governing who’s even allowed to use either are actually configured.

The Core Problem: Most Actions Shouldn’t Need Full Root Access

Root — sometimes called the superuser — is the one account on a Linux system with no permission restrictions at all. Every check covered in the Permissions section, every ownership rule, every ACL — root bypasses all of it by design. That’s necessary for a system to function (someone needs to be able to fix anything), but it’s also exactly why staying logged in as root all the time is a bad idea: there’s no permission system left standing between a mistake and the entire machine.

The two commands in this chapter exist to solve the same underlying problem differently: how do you get root-level access only for the moment you actually need it, without living inside that account full-time?

su: Switch User

su (“switch user”) starts a new shell session as a different user — by default, root, if you don’t specify anyone else.

su

This prompts for root’s own password, and if correct, drops you into a full root shell — your prompt changes to the # symbol from the Terminal & Shell Basics chapter, and everything you type from that point runs with unrestricted root privileges, until you explicitly exit that shell.

su alice

This switches to alice’s account instead, prompting for alice’s password.

The core issue with su for everyday use is exactly what its behavior implies: it requires knowing the target account’s actual password, and once you’re in, you stay in — an entire session running as root, with no distinction between the one command you actually needed elevated and everything else you might type afterward, intentionally or by mistake.

sudo: Superuser Do

sudo takes a fundamentally different approach: instead of switching into a persistent root session, it runs one single command with root privileges, then immediately returns you to your normal account.

sudo apt update

This runs just that one apt update command as root, then drops you straight back to your regular $ prompt — no separate session, nothing left elevated afterward. You’ve been using exactly this pattern throughout the last two sections.

A few behavioral details worth knowing:

  • sudo asks for your own password, not root’s — which also means a system can have sudo fully configured and working without root ever needing a usable password of its own at all, a genuinely common secure setup.
  • Once you’ve authenticated, sudo remembers it for a short window (commonly 15 minutes) so you’re not re-entering your password for every single command in a row.
  • Not every user can run sudo at all — it only works for accounts explicitly granted permission, which is where /etc/sudoers comes in next.
    flowchart LR
    A["su"] --> B["Enter root's password"]
    B --> C["Full root shell session<br/>stays elevated until you exit"]
    D["sudo command"] --> E["Enter YOUR password"]
    E --> F["That one command runs as root<br/>immediately back to normal"]

Why sudo Is Generally The Safer Default

Three concrete advantages, beyond just “it’s the modern convention”:

Scope. A mistake typed while a full root shell is open affects everything you type in that session. A mistake typed as sudo <command> is contained to that one command — the next thing you type is back to being an ordinary, permission-checked action.

Accountability. sudo usage is logged, by default, to the system log — every elevated command, and who ran it, tied to your account rather than an anonymous root session. su gives you the same unrestricted access with none of that per-user trail.

Granularity. sudo can be configured to grant a specific user permission for only specific commands, rather than all-or-nothing root access — something su has no concept of at all, since it hands over the entire root account or nothing.

Where The Rules Live: /etc/sudoers

Whether a given user can run sudo at all — and what they’re allowed to run it on — is controlled by /etc/sudoers. You can look at it, but there’s an important rule about editing it:

sudo cat /etc/sudoers

You’ll see lines like:

root    ALL=(ALL:ALL) ALL
%sudo   ALL=(ALL:ALL) ALL

Read the second line as: any user in the group sudo (the % prefix means “this is a group, not a username”) is allowed to run any command, as any user, on any host. This is exactly why adding a user to the sudo group in the last chapter — usermod -aG sudo alice — was enough to grant them full sudo access, without editing this file directly at all. On Debian-based systems specifically, membership in the sudo group is the standard mechanism; that’s a Debian-family convention, not a universal one — some distributions use a differently named group for the same purpose.

Warning

Never edit /etc/sudoers directly with nano or any regular editor. A syntax error in this file can break sudo entirely — including for you — potentially locking every user out of elevated access at once, with no sudo left available to fix the very file that broke it. Use visudo instead:

sudo visudo

visudo opens the file in your configured editor exactly like normal, but validates the syntax before saving, refusing to write a broken file and telling you exactly what’s wrong instead. This is the one file on the entire system where reaching for a plain editor is a genuinely dangerous habit.

Reading A sudoers Line, Field By Field

The two lines you’ve already seen — root ALL=(ALL:ALL) ALL and %sudo ALL=(ALL:ALL) ALL — follow a fixed structure worth breaking down properly, since the moment you need anything more specific than “full access,” you’re writing this syntax yourself.

who    where=(as_whom) what
  • who — a username, or a group prefixed with % (exactly as seen with %sudo)
  • where — which host(s) this rule applies to. On a single machine this is always ALL, but /etc/sudoers is designed to be shareable across many machines at once, where a rule might apply only to specific hostnames — outside the scope of what you’ll need here, but worth knowing why the field exists at all.
  • (as_whom) — which user (and optionally group) the commands can be run as. (ALL:ALL) means “as any user, as any group” — root included. A narrower rule might read (www-data), permitting that user to run commands only as www-data, never as root.
  • what — the actual command(s) permitted. ALL means unrestricted; this can instead be a specific, comma-separated list of full command paths.

A more restrictive real example:

alice   ALL=(root) /usr/bin/systemctl restart nginx

This grants alice permission to run exactly one command as root — restarting nginx — and nothing else. Trying to run any other command with sudo fails, even though she has sudo access at all.

A Worked Example: A Narrowly Scoped Temporary User

To see this in action without touching your real access, create a throwaway account:

sudo useradd -m -s /bin/bash tempadmin
sudo passwd tempadmin

Then grant it exactly one privileged capability — restarting nginx, nothing more — using visudo as covered earlier in this file:

sudo visudo

Add:

tempadmin   ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx

That NOPASSWD: tag is new — it skips the password prompt entirely for this specific rule, letting tempadmin run just this one command without authenticating at all. Log in as tempadmin (or su - tempadmin) and confirm:

sudo systemctl restart nginx
sudo whoami

The first command succeeds silently. The second — an entirely different command — is refused, even though it looks harmless, because it isn’t the one exact command this rule permits.

Warning

NOPASSWD is convenient for automation but removes the one authentication check standing between “this account is compromised” and “this account has already run something as root.” Use it deliberately, scoped to the narrowest possible command, never as a blanket convenience — and never on a rule granting ALL commands, which would functionally hand out passwordless root.

Clean up once you’re done experimenting:

sudo userdel -r tempadmin
sudo visudo

(Remove the tempadmin line from inside visudo manually — there’s no separate command for removing a single sudoers entry.)

What’s Next

That closes out Section 4 — you can now read and manage users and groups, and you understand exactly what’s happening every time you type sudo. The next few sections explain core networking and processes in linux.

Last updated on
Managing Users and Groups