Skip to main content

Sudo explained

· 5 min read

What sudo does​

Sudo lets an authorized user run a specific command as another user — almost always root — without logging in as that user or ever knowing their password. It checks the request against a policy file, runs the command with elevated privileges if the policy allows it, and logs what happened.

That's the whole job: controlled, audited privilege escalation. Everything else in this post is about how it pulls that off.

Why not just log in as root​

You could skip sudo entirely and work as root directly. Don't. Every command you run as root executes with no safety net — a typo in rm -rf or a misdirected chown can take down a system in one keystroke, and there's no record of who did it if the box is shared.

Sudo fixes both problems at once. Users keep their own accounts and their own passwords. Root access is granted per command, per user, through a policy file the administrator controls. And every invocation is logged — which user, which command, when.

Example of use​

Ordinary users can't read /etc/shadow:

$ cat /etc/shadow
cat: /etc/shadow: Permission denied

A user listed in the sudoers file can run the same command through sudo:

$ sudo cat /etc/shadow
[sudo] password for user:

root::18295:0:99999:7:::
daemon::18295:0:99999:7:::
bin:*:18295:0:99999:7:::
...

Same command, same user, different outcome — because sudo, not the user, is the one actually reading the file.

What happens on each invocation​

When you type sudo <command>, this is the sequence:

  1. Session cache check — sudo looks for a cached authentication from a recent sudo session.
  2. Password prompt — if nothing's cached, it asks for your password.
  3. Authentication — your password is verified through PAM (Pluggable Authentication Modules).
  4. Policy check — sudo reads /etc/sudoers to see whether you're allowed to run this command as this target user.
  5. Execution — if allowed, the command runs with the target user's privileges.
  6. Logging — the invocation, the command, and the outcome are recorded.

Step 4 raises a question worth sitting with: /etc/sudoers is owned by root and unreadable by anyone else. How does a program invoked by an unprivileged user read a root-only file to decide whether that same user is allowed to escalate?

The SUID bit is what makes it possible​

Look at the permissions on the sudo binary itself:

$ ls -l /usr/bin/sudo
-rwsr-xr-x 1 root root [size] [date] usr/bin/sudo

That s in place of the owner's execute bit is the SUID (Set User ID) flag. A SUID binary runs with the privileges of its owner, not its invoker. Sudo is owned by root, so sudo always runs as root — regardless of which user launched it. That's how it reads /etc/sudoers, and it's the same mechanism that lets it write to /etc/shadow on your behalf in the earlier example.

This also means the sudo binary itself is a high-value target. A vulnerability in sudo is a vulnerability in a program that always runs as root, no matter who triggers it. That's why sudo has had a steady stream of CVEs over the years, and why keeping it patched isn't optional the way it might be for a less privileged tool.

tip

Sudo is open source, maintained by Todd C. Miller, with an active release history. Current version and release date: 1.9.17p2, July 26, 2025. Details at the official site.

Logging and its limits​

Every sudo invocation is recorded — on Debian/Ubuntu, in /var/log/auth.log:

grep sudo /var/log/auth.log

This is useful for auditing and incident response, but don't treat it as a complete picture. Logs capture the command that was run, not necessarily what that command did once it had root privileges — sudo bash followed by arbitrary commands inside that shell won't show up line by line. If you're relying on sudo logs for detection, you need to know where that visibility ends.

Where sudo gets misused​

The mechanism is sound; the failure mode is almost always configuration. Two patterns come up repeatedly:

  • Overly broad sudoers entries. user ALL=(ALL) NOPASSWD: ALL gives a user unrestricted, unauthenticated root access — functionally equivalent to giving them the root password, minus the audit trail benefit sudo was supposed to provide.
  • Commands that allow escape to a shell. If a sudoers entry permits a command like less or vim without restriction, the user can spawn a root shell from inside it. The sudoers file grants a command, not a guarantee that the command can't be abused to get a shell.

Least privilege is the whole point of sudo. A permissive sudoers file defeats it just as thoroughly as not using sudo at all.

What this means in practice​

Sudo is a SUID-root binary that mediates privilege escalation through a policy file, with logging built in. That's the answer if you're asked "what is sudo and how does it work" in an interview, and it's also the checklist for running it safely:

  1. Keep sudoers entries as narrow as the task requires — specific commands, specific users, not ALL=(ALL) ALL.
  2. Watch for commands that can shell out, and restrict or avoid them in sudoers.
  3. Monitor sudo logs, knowing they show invocation, not execution detail.
  4. Have a response plan for sudo misuse or a compromised sudo binary.
  5. Keep sudo itself patched — it's a root-privileged attack surface by design.