sudo

Translation(s): العربية - English - Español - Français - Italiano - Русский

Root > sudo

Sudo (sometimes said to stand for Super-user do) is a program designed to let system administrators allow some users to execute some commands as root (or any other user). The basic philosophy is to give as few privileges as possible. Sudo can also be used to log which user ran a command and when.

Contents

Reasons people do and do not use sudo
Installing sudo
Configuring sudo
Granting sudo access
1. Verifying sudo membership
Problems and tips
1. Sorry, user jdoe is not allowed to execute ...
2. sudoers is read-only
See also

Reasons people do and do not use sudo

Historically, Unix-like systems did not use sudo. But since the change of the century, sudo (or its numerous alternatives to do more fine-grained privilege escalation) is almost omnipresent in the Linux world, regardless whether it's a privately-owned single-machine installation or a huge datacenter with hundreds of thousands of machines.

In cloud and/or container environments with their ephemeral instances, sudo is kind of uncommon since cloud instances and containers usually don't have user accounts in the first place.

Why people use sudo

Using sudo (instead of logging in as root, su'ing to root or running everything with full privileges) addresses several operational and security concerns:

Principle of least privilege

You execute commands with elevated privileges only when required. The rest of the session runs unprivileged, reducing the blast radius of mistakes or compromised processes.

Auditability and accountability

sudo logs command execution (typically via syslog or journald). You get:

who ran a command
when it was run
what exactly was executed

Leaving this kind of audit trail is important for multi-user systems and might be helpful in environments with compliance requirements.

Reduced attack surface

No need to enable direct root login (especially over SSH). Users authenticate with their own credentials, not a shared root password. Limits exposure to brute-force or credential reuse attacks targeting root.

No need to share the root password

When working in teams, everybody logs in and escalates privilege with their own password. Noone needs to know the root password, making it possible to use the root password as a method for emergency access. Many installations have the same root password on all machines with the only copy of the cleartext password somewhere in a vault where only the CTO and their deputies have access to.

When a person leaves, only their account gets locked. When a password gets compromised, only that person's password needs to be changed while the other team members can continue working without being affected.

Fine-grained access control

Via /etc/sudoers (or drop-ins in /etc/sudoers.d), you can:

allow specific commands only
restrict by host, user, or group
require or skip password prompts (NOPASSWD)

This enables delegation without full root access.

Safer shell behavior

Working as root interactively is error-prone:

typos (rm -rf /) become catastrophic
scripts may behave differently under root
accidental pastes might be harmful

With sudo, privilege escalation is explicit per command.

Better integration with modern tooling

Many system tools assume sudo-style escalation rather than root login:

package managers (apt, dnf)
service management (systemctl)
configuration management systems

Session timeout and re-authentication

sudo credentials expire after a configurable timeout. This limits damage if a terminal is left unattended.

Separation of duties

You can give operators controlled administrative capabilities without giving them unrestricted root shells.

Why some people do not use sudo

Added complexity without benefit

On a single-user system:

No meaningful separation of duties
No audit value
Extra configuration (sudoers) to maintain

Logging in as root directly can be simpler and more transparent.

Big Code Base

Sudo is a rather big and complex suid root binary. It introduces the possibility of unintended privilege escalation in case of software bugs. There are alternatives available that have more modern and smaller code base, doing almost the same job.

False sense of security

sudo does not inherently make a system secure:

Users with broad ALL=(ALL) ALL effectively are root
Misconfigured sudoers (e.g. NOPASSWD, overly permissive rules) negate protections
Attackers gaining user access often escalate via sudo anyway

Credential exposure and caching

Password entry for sudo increases exposure to keyloggers or shoulder surfing
Timestamp caching (timestamp_timeout) allows privilege reuse without re-authentication
sudo -s / sudo -i can create long-lived root shells, defeating the model

Operational friction

Repeated sudo prefixes in workflows and scripts
Breaks copy/paste of command sequences unless adjusted
Encourages patterns like sudo sh -c "...", which are harder to reason about and audit

In practice, people often bypass this by spawning a root shell anyway.

Script and automation issues

sudo in scripts introduces interactivity problems (password prompts)
Requires extra handling (NOPASSWD, askpass, environment tweaks)
In automation contexts (CI, containers, init), running as root directly is cleaner

Environment inconsistencies

sudo resets or filters environment variables (env_reset)
Leads to subtle bugs (PATH differences, missing variables)
Requires explicit preservation (sudo -E), which weakens security guarantees

Not universally available or consistent

Minimal systems, embedded environments, containers often omit sudo
Different systems have different sudoers policies, reducing portability

Encourages partial privilege thinking

Instead of designing proper privilege boundaries (capabilities, service separation), people:

grant sudo access broadly
rely on it as a catch-all escalation mechanism

This can be inferior to:

dedicated service accounts
Linux capabilities (setcap)
tightly scoped daemons

Root shell is sometimes clearer

For complex administrative tasks, a controlled root session (su - or equivalent)

avoids repeated escalation
Reduces risk of mixing privileged/unprivileged file ownership unintentionally
Makes execution context explicit and consistent

Summary

sudo is primarily about control, traceability, and minimizing risk, not just convenience. It enforces a discipline around privilege escalation that scales from personal systems to large multi-user infrastructures.

Caveats

Be careful when granting permission to execute certain commands only. If the commands allowed can be abused for privilege escalation (most easy: a shell escape, should you allow a reasonably powerful editor, for example), then allowing users to execute that command will effectively make those users root. For the special case of editing files that are only writeable for root, the command sudoedit is available that will make a copy of the file that can be written by the calling user, then call the editor as the calling user (making a shell escape inefficient as privilege escalation) and then copy the file back.

When working in a team, be aware that malicious team members can use their privileges to build themselves a backdoor that they can still use after their sudo privileges or even their system account was removed. sudo doesn't free you from the "once root, always root" rule that comes with Unix systems.

No useable audit trail is left behind when a careless user uses sudo -i or sudo -s to obtain a root shell. If a team wants to have an audit trail, they need to agree on using sudo for every single command, never ever calling up a root shell, and to abide by that agreement.

This is also a reason why switching to root using sudo -i (or sudo su) is usually deprecated because it cancels most of the above features.

Alternatives

Lot of Debian administrators do not install sudo. Instead, they run commands as root (for example with su - from a normal user account) when they need.

There are other programs, such as

run0
run_as
sudo-rs
super

that can do the same job as sudo without being so complex and extensively configurable. In practise, those alternative are seldomly seen in use.

Installing sudo

Installation of sudo happens during the Install if you decide to not set a password for root. In that case, the system user you create during installation becomes member of the sudo group and is thus permitted to sudo to root and any other user for any comment. This is the way other end-user oriented distributions work as well. The system will also configure gksu and aptitude to use sudo.

If you set a root password during install, sudo does not get installed and the (optional) user you create in addition does not end up in the sudo group. This kind of installation more closely resembles a historical Unix setup. If you want sudo on such a system, you need to become root differently, install the sudo package with apt and optionally add the users you want to be root equivalent to the sudo group.

$ su --login
Password: 
## (enter here the password of the root user that you specified during your Debian installation, and press Enter)

# apt install sudo

# adduser jhon-smith sudo

(Obviously replace "jhon-smith" with your personal username)

As usual, group membership is only set on login, so if you just added yourself to the sudo group, you must completely log out and log in again for your new group membership to get valid. The newgrp command can be used to temporarily add the new group for a single shell session if you dont want to log out at this time.

Configuring sudo

The main sudo configuration file is /etc/sudoers. This file is read-only, even for root: there is a visudo command which allows root to edit the file but it is better to put local configuration in files in /etc/sudoers.d. Using /etc/sudoers.d/ will ensure local changes remain in effect, even if the Debian package maintainer changes /etc/sudoers in a new version of the sudo package.

The /etc/sudoers file that comes with the Debian package is extensively commented and contains a reasonably secure default configurtion and some examples.

Requiring the root password

If you want to require the root password for use of sudo, rather than the user's password, add the line:

Defaults   rootpw

to a file in /etc/sudoers.d. This kind of defeats a big part of sudo's purpose, so it is not recommended to do so.

Not requiring any password

If you want sudo group members to execute commands without any password (which is usually a bad idea), add the line:

%sudo ALL=(ALL) NOPASSWD: ALL

to a file in /etc/sudoers.d. Be aware that this will allow anyone compromising that user account to obtain root access very easily.

NOPASSWD is often used to allow automated processes to escalate privileges automatically. Consider the implications plase.

Customizing the timeout period

By default, after asking for a password, your credentials are cached by sudo for 15 minutes. You can change this behavior by setting a different timeout for a specific user:

Defaults:foobar timestamp_timeout=30

Granting sudo access

Debian's default configuration allows users in the sudo group to run any command via sudo.

Verifying sudo membership

Once logged in as a user, you can verify whether or not the user belongs to group=sudo using either the id or groups commands. E.g., a user with id=foo should see:

```
$ groups
foo sudo
```

If sudo is not present in the output, the user does not belong to the sudo group. Similarly, the output from command=id should look something like

uid=1001(foo) gid=1001(foo) groups=1001(foo),27(sudo)

Problems and tips

Sorry, user jdoe is not allowed to execute ...

If you get an error like this:

$ sudo test

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

[sudo] password for jdoe: 
Sorry, user jdoe is not allowed to execute '/usr/bin/test' as root on localhost.

This message means what it says: the user you're running as isn't allowed to execute the given command on the given machine. One confusing possible reason for this is that the administrator has just added user jdoe to a privileged group - but you're still using the old login, which doesn't have that new group information, and therefore has no new sudo-ing rights. People in this situation are usually advised to log out completely and back in again, though you can sometimes get away with just performing a "re-login on the spot" with su - $USER or changing group with newgrp sudo.

sudoers is read-only

Yes, the file /etc/sudoers is intentionally set read-only, even for root!

The explanation is that it was set up this way to motivate admins to only ever edit it via the command visudo, which provides additional checking before leaving the new file in place. You might think that the fix for a mangled /etc/sudoers, the fix may be as simple as su -c visudo, but sudo is often used in a place where simply su'ing to root is not possible since you simply don't know the root password.

Beware, most text editors will let you edit the file without complaining about the read-only bit, so you might not automatically get this additional protection.