sudo is a Linux and Unix command that allows a permitted user to run a command with the privileges of another user, by default the root account, after authenticating with the user’s own password. Which users may run which commands, as whom and on which hosts is defined in a policy file called sudoers, and every use is logged.
In Linux permissions, sudo is the standard mechanism for delegated, temporary privilege elevation. Instead of sharing the root password and working in a root shell, administrators stay logged in as ordinary users and elevate only the commands that need it. This limits accidental damage, gives every privileged action a named owner in the logs and allows fine-grained delegation, such as letting a support team restart one service and nothing else.
How sudo grants privileges
The sudo program is installed with the setuid bit and owned by root, so it starts with root privileges regardless of who runs it. It then checks the sudoers policy, authenticates the caller, usually through PAM, and only if the request is allowed does it start the command as the target user. Otherwise it refuses and records the attempt.
After a successful authentication, sudo caches the credential for a short period, by default five minutes in upstream sudo, although distributions may change it. During this window, further sudo commands in the same terminal do not ask for the password again. The cache is controlled by the timestamp_timeout option and can be cleared with sudo -k.
Every invocation produces a log entry with the calling user, the terminal, the working directory, the target user and the full command line. Depending on the distribution, these entries go to /var/log/auth.log, /var/log/secure or the systemd journal, and they are usually forwarded to central logging so that a local root user cannot quietly erase the trail.
The table lists the options most often used in daily administration.
| Command | Effect | Typical use |
|---|---|---|
| sudo command | Run one command as root | Installing packages, editing system files |
| sudo -u user command | Run as a specific non-root user | Running jobs as a service account |
| sudo -l | List what the caller may run | Checking delegated permissions |
| sudo -e file | Edit a file safely as another user | Changing root-owned configuration |
| sudo -i | Start a root login shell | Longer administrative sessions |
| sudo -k | Discard cached credentials | Before leaving a terminal unattended |
The sudoers policy
The policy lives in /etc/sudoers and in drop-in files under /etc/sudoers.d. A rule has the form user, host, run-as identity and command list, for example %ops ALL=(root) /usr/bin/systemctl restart nginx, which lets members of the ops group restart one service. Distributions grant full rights to an administrative group, sudo on Debian and Ubuntu and wheel on Fedora and RHEL.
The file must always be edited with visudo, which locks it and checks the syntax before saving. A syntax error in sudoers can disable sudo entirely, which on systems without a root password leaves no easy way to regain administrative access.
| Setting | Purpose | Recommended practice |
|---|---|---|
| NOPASSWD tag | Skips authentication for listed commands | Only for narrowly defined automation commands |
| env_reset | Removes most environment variables | Keep enabled to block environment-based attacks |
| secure_path | Sets a trusted PATH for commands | Keep enabled so user PATH entries are ignored |
| timestamp_timeout | Length of the credential cache in minutes | Short values, zero for very sensitive hosts |
| log_output and I/O logging | Records session input and output | Use where audits require full session records |
sudo compared with su and other tools
sudo is not the only way to gain elevated privileges. The main alternatives differ in whose password is required and how fine-grained the control is.
| Tool | Authentication | Granularity | Typical context |
|---|---|---|---|
| sudo | Caller’s own password | Per user, command and target user | Most Linux servers and desktops |
| su | Target user’s password | Full shell as that user | Systems with a shared root password |
| doas | Caller’s own password | Simpler rule set | Minimalist systems, from OpenBSD |
| pkexec | Through polkit policies | Per action defined by applications | Desktop administration dialogs |
| run0 | Through polkit, via systemd | Per action, no setuid binary | Newer systemd-based systems |
sudo’s large feature set is also a security concern: more code means a larger attack surface, and serious vulnerabilities have been found in it over the years. This has motivated simpler tools and a memory-safe reimplementation, sudo-rs, which some distributions have started to ship by default.
Pitfalls and security mistakes
A rule that looks narrow can still grant full root access. Programs such as text editors, pagers, interpreters and tools like find or tar can spawn a shell, so allowing sudo vim or sudo less effectively allows everything. Wildcards in command arguments are similarly risky because users can append unexpected options.
- Redirection runs without privilege: in
sudo echo text > /etc/file, the shell opens the file as the user; usesudo teeinstead. - Writable scripts listed in sudoers can be modified by the user and then run as root.
- Broad NOPASSWD rules turn any compromise of the user account into root access.
- Shared accounts defeat the main audit benefit, because logs no longer identify a person.
- Prefer sudoedit for file edits, because the editor runs as the user, not as root.
The short version
Think of an office building where most employees have badges for ordinary rooms. For the server room, they ask security to open the door just once, and every visit is written in a logbook.
sudo is that supervised door. It lets a normal user perform one administrator task at a time, using their own password. Nobody has to share a master key, and it is always clear who did what and when.
Where it makes a difference
A company’s web servers are managed by four administrators and a night support team. Previously, everyone used the shared root password, so when a configuration file was deleted at 2 a.m., nobody could tell who had done it. The security team disables direct root login and gives the administrators full sudo rights through the sudo group.
The support team receives a single drop-in rule that allows only restarting the web server and reading its logs, without shell access. Three months later, an outage is traced within minutes: the authentication log shows which named account ran which command, and the team corrects a deployment script instead of guessing.