Linux command: sudo

Type one wrong command as an ordinary user and Linux stops you with Permission denied. Put the four letters sudo in front of it and, after your own password, the same command runs with the full power of the system. That small word is the front door to root on almost every Linux server. It looks trivial, but behind it sits a careful policy engine, a setuid trick, and a rule file that decides exactly who may do what.

2. Where the Name Comes From

The name sudo is usually read as superuser do: "do this as the superuser".

sudo  =  SuperUser DO

There is a second, more precise reading. Because sudo can run a command as any user, not only root, it is also explained as substitute user do: "do this as a substitute user". Both readings are common, and the manual page itself simply says "execute a command as another user", which covers both.

The related older command su follows the same logic. It is short for substitute user (often mis-remembered as "superuser"), and it switches your whole session to another user. sudo was designed as a safer, finer-grained relative of su, which is why the names rhyme.

4. Simple Use Cases

4.1 Running One Command as Root

This is the everyday case. You put sudo in front of a command that needs administrative rights:

$ apt install htop
E: Could not open lock file /var/lib/dpkg/lock-frontend - Permission denied

$ sudo apt install htop
[sudo] password for peter:
Reading package lists... Done

Only the command right after sudo runs with extra rights. Everything before and after it is still plain you.

4.2 Fixing a Forgotten sudo: the Magic sudo !!

You run a command, it fails for lack of permission, and you realise you forgot sudo. Instead of typing the whole line again, repeat the previous command with !! (the shell's "last command" shortcut):

$ systemctl restart nginx
Failed to restart nginx.service: Access denied

$ sudo !!
sudo systemctl restart nginx
[sudo] password for peter:

The shell expands !! into the previous command, so sudo !! becomes "run that same command again, but as root". It is one of the most-loved shortcuts in daily Linux work.

4.3 Running as a Different User

By default sudo runs the command as root, but the -u flag (short for user) lets you name any target user. This is common when a service runs under its own account:

$ sudo -u postgres psql       # run psql as the postgres user
$ sudo -u www-data whoami     # confirm the identity
www-data

So "sudo" does not always mean "root". It means "run as the user policy allows", and root is only the default.

4.4 Checking What You May Do: -l

Before you go looking for a password, you can ask sudo what it will let you do. The -l flag (short for list) prints your privileges:

$ sudo -l
User peter may run the following commands on server:
    (ALL : ALL) ALL

The line (ALL : ALL) ALL means "as any user, as any group, run any command". A more limited account might instead show a single service it is allowed to restart, and nothing else.

6. Advanced Use Cases

6.1 The sudoers File and visudo

All of sudo's decisions come from one policy file: /etc/sudoers. It lists who may run which commands, as whom, and whether a password is required. You never edit it with a plain text editor. You use visudo, which locks the file, opens your editor, and, crucially, checks the syntax before saving:

$ sudo visudo

That syntax check is not a nicety. A single typo in /etc/sudoers can lock every user out of sudo at once, and then you have no easy way back in. visudo refuses to save a broken file, which has rescued countless administrators.

A few lines from a typical sudoers file explain the format:

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

Read the second line left to right: the %sudo means "members of the group named sudo", the first ALL is "on any host", (ALL:ALL) is "may run as any user and any group", and the last ALL is "any command". The leading % is what marks a group rather than a single user.

6.2 Drop-in Files: /etc/sudoers.d/

Rather than editing the main file, modern practice is to add a small file in the /etc/sudoers.d/ directory. Each file there is read as part of the policy, which keeps custom rules separate and easy to remove. Always create them with visudo -f so the syntax is still checked:

$ sudo visudo -f /etc/sudoers.d/deploy

6.3 Passwordless Commands: NOPASSWD

Sometimes a script or an automation account must run one specific command as root without stopping for a password. The NOPASSWD tag allows exactly that, and only that:

deploy  ALL=(root) NOPASSWD: /usr/bin/systemctl restart myapp

This lets the deploy user restart one service, with no password, and do nothing else as root. That is the right way to use NOPASSWD: narrow it to a single, exact command. Granting NOPASSWD: ALL hands out full passwordless root and throws the safety away.

6.4 A Login Shell or a Plain Shell: -i and -s

When you really do need an interactive root shell, two flags give it to you:

$ sudo -i      # a full login shell as root (loads root's environment)
$ sudo -s      # a shell as root, but keep your own environment

The -i flag (short for login) behaves as if root had just logged in: it moves to root's home directory and reads root's startup files. The -s flag (short for shell) starts a root shell but stays in your current directory with much of your own environment. Use these sparingly; the whole spirit of sudo is one command at a time.

6.5 Editing Files Safely: sudoedit

A very common task is editing a root-owned config file. The tempting way is sudo vim /etc/nginx/nginx.conf, but that runs your entire editor as root, with all its plugins and shell escapes, which is more power than the job needs. The safer tool is sudoedit, also reachable as sudo -e:

$ sudoedit /etc/nginx/nginx.conf
$ sudo -e /etc/nginx/nginx.conf     # exactly the same thing

What happens under the hood is clever. sudoedit copies the file to a temporary place, runs your editor as you (not as root), and only writes the result back as root when you save. Your editor never runs with root's power, which closes a whole class of security holes. It also respects your own $EDITOR setting.

6.6 The Environment: env_reset and secure_path

For safety, sudo does not simply carry your environment into the root command. By default (the env_reset option) it starts from a clean, minimal environment and uses a fixed, trusted secure_path for finding programs. This stops a user from pointing PATH at a malicious fake command and having root run it.

Two consequences catch people out. First, a variable you exported may not be visible inside sudo; pass it through with -E (short for preserve-env) or name it explicitly:

$ sudo -E ./deploy.sh                 # keep the whole environment
$ sudo --preserve-env=HTTP_PROXY cmd  # keep just one variable

Second, a program in an unusual directory may be "not found" under sudo even though your shell finds it, because secure_path is deliberately short. Give the full path in that case.

8. Best Practices

• Use sudo, not a root login. Running individual commands with sudo keeps a log, uses your own password, and lets you drop straight back to a safe, ordinary account.
• Always edit the policy with visudo. Never open /etc/sudoers directly. The syntax check that visudo performs is what stands between you and being locked out.
• Prefer drop-in files. Put custom rules in /etc/sudoers.d/ (created with visudo -f) so they are easy to review and remove without touching the main file.
• Grant the least you can. If an account only needs to restart one service, write exactly that command in the rule. Avoid handing out (ALL) ALL when a single line will do.
• Edit files with sudoedit. Reach for sudoedit file instead of sudo vim file so your editor never runs with root's power.
• Be very careful with NOPASSWD. It is useful for one narrow automated command, but NOPASSWD: ALL gives away full passwordless root.
• Read the manual when unsure. The behaviour is all documented, and typing man sudo or man sudoers is the mark of a careful administrator.

$ man sudo         # the sudo command itself
$ man sudoers      # the policy file format, with many examples
$ sudo --help      # a quick summary of the options

10. Summary

The sudo command is short, but it governs the most important question on a Linux system: who is allowed to act as root, and for exactly what.

• sudo runs a single command as another user, normally root, after asking for your own password.
• The name reads as "superuser do" (or "substitute user do", since it can run as any user).
• It was written around 1980 at SUNY/Buffalo and is now maintained as the Sudo project; Ubuntu made it the standard way to gain root.
• Put it in front of a command; use sudo !! to repeat the last one as root, and -u to run as a specific user.
• A timestamp remembers you for 15 minutes; -v refreshes it and -k forgets it.
• Permission comes from a group, sudo on Debian and Ubuntu, wheel on Red Hat and Fedora.
• The policy lives in /etc/sudoers and drop-in files under /etc/sudoers.d/, always edited with visudo.
• Use sudoedit to change root-owned files safely, and -i or -s only when you truly need a root shell.
• sudo works because its binary is setuid root; that is also why it must be kept owned by root and up to date.
• Under the hood it sets the process's real, effective, and saved user IDs to the target, and checks your password through PAM.
• Every use is logged, which is one of its biggest advantages over logging in as root.

This is the quick reference worth keeping:

sudo command             run one command as root
sudo -u user command     run it as another user
sudo !!                  repeat the previous command as root
sudo -l                  list what you are allowed to run
sudo -v                  refresh the 15-minute timestamp
sudo -k                  forget the timestamp now
sudo -i                  a full root login shell
sudoedit /etc/file       edit a root-owned file safely
echo x | sudo tee file   write to a root-owned file
sudo visudo              edit the sudoers policy safely
sudo usermod -aG sudo u  grant a user sudo rights (Debian/Ubuntu)

Getting sudo right is one of the quiet foundations of a secure server: the difference between a machine where every action is scoped and logged, and one where a single shared root password floats around. If you are unsure whether your server's sudo rules grant too much, or you want passwordless automation set up without opening a hole, it pays to have someone review the whole policy properly before a convenient NOPASSWD: ALL becomes tomorrow's incident.