SUDO(8)

📦 version 1.9.17p2, in ubuntu questing, ubuntu resolute, ubuntu stonking

✨ SUDO(8) · System Manager's Manual ✨

🎀 NAME

okay so the name section is short and sweet 🌸: sudo, sudoedit — execute a command as another user 💅

🧾 SYNOPSIS

sudo -h | -K | -k | -V
sudo -v [-ABkNnS] [-g group] [-h host] [-p prompt] [-u user]
sudo -l [-ABkNnS] [-g group] [-h host] [-p prompt] [-U user] [-u user]
     [command [arg ...]]
sudo [-ABbEHnPS] [-C num] [-D directory] [-g group] [-h host]
     [-p prompt] [-R directory] [-r role] [-t type] [-T timeout]
     [-u user] [VAR=value] [-i | -s] [command [arg ...]]
sudoedit [-ABkNnS] [-C num] [-D directory] [-g group] [-h host]
     [-p prompt] [-R directory] [-r role] [-t type] [-T timeout]
     [-u user] file ...

💖 DESCRIPTION

okay so sudo lets a user who's allowed to do it run a command as the superuser or some other user 👑, as long as the security policy says yes. The user name that gets checked against the policy comes from the invoking user's real user-ID, not their effective one 🦋.

sudo has a plugin architecture for security policies, auditing, and input/output logging ✨. Third parties can build and share their own plugins that play nicely with the sudo front-end 🧚. The default security policy is sudoers, which is configured through the file /etc/sudoers, or through LDAP 🌈. See the “Plugins” section for more info 💜.

The security policy decides what privileges, if any, a user gets when running sudo 🔥. It might make the user prove who they are with a password or some other authentication method. If authentication is required and the password isn't entered within a configurable time limit, sudo exits 💀. That limit is policy-specific, and the default password prompt timeout for the sudoers security policy is 0 minutes, so no pressure 🙈.

Security policies may support credential caching, which lets the user run sudo again for a while without re-authenticating ⏰. By default, the sudoers policy caches credentials per terminal for 15 minutes 🍓. See the timestamp_type and timestamp_timeout options in sudoers(5) for more details. Running sudo with the -v option refreshes the cached credentials without running a command 🫶.

⚠️ On systems where sudo is the main way to get superuser privileges, it is imperative to avoid syntax errors in the security policy configuration files 😭. For the default security policy, sudoers(5), make your changes with the visudo(8) utility, which makes sure no syntax errors sneak in 🛡️.

When invoked as sudoedit, the -e option (described below) is implied 📝.

Security policies and audit plugins may log successful and failed attempts to run sudo 👀. If an I/O plugin is configured, the running command's input and output may get logged too 🎬.

🎀 OPTIONS

The options are as follows, bestie 💅:

  • -A, --askpass — normally, if sudo needs a password, it reads it straight from the user's terminal. With -A (askpass), a helper program (possibly graphical 🪟) is run instead, which reads the password and prints it to the standard output. If the SUDO_ASKPASS environment variable is set, it holds the path to that helper program. Otherwise, if sudo.conf(5) has a line naming the askpass program, that value gets used. For example:
# Path to askpass helper program
Path askpass /usr/bin/ssh-askpass

If there's no askpass program available, sudo exits with an error 😤.

  • -B, --bell — rings the bell as part of the password prompt when a terminal is present 🔔. This does nothing if an askpass program is being used 🙃.
  • -b, --background — runs the given command in the background 🌙. You can't use shell job control to manage background processes started by sudo, so most interactive commands will fail to work properly in background mode 💀.
  • -C num, --close-from=num — closes all file descriptors greater than or equal to num before running a command 🚪. Values less than 3 aren't allowed 🚫. By default, sudo closes every open file descriptor except standard input, standard output, and standard error when it runs a command. The security policy might restrict your ability to use this option. The sudoers policy only lets you use -C if the administrator has turned on the closefrom_override option 🔒.
  • -D directory, --chdir=directory — runs the command in the specified directory instead of the current working directory 📂. The security policy may throw an error if you don't have permission to pick the working directory 🙅.
  • -E, --preserve-env — tells the security policy that you want to keep your existing environment variables ✨. The policy may return an error if you don't have permission to preserve the environment 🥲.
  • --preserve-env=list — tells the security policy you want to add the comma-separated list of environment variables to the ones preserved from your environment 🍓. Same deal as above: the policy may error if you aren't allowed to preserve the environment. This option can be specified multiple times 🔁.
  • -e, --edit — edits one or more files instead of running a command 📝. Instead of a path name, the string "sudoedit" is used when consulting the security policy 🕵️. If the policy authorizes you, these steps happen:
    1. Temporary copies are made of the files to be edited, with the owner set to the invoking user 🧑‍🎨.
    2. The editor specified by the policy runs to edit the temporary files. The sudoers policy checks the SUDO_EDITOR, VISUAL and EDITOR environment variables (in that order) 🖊️. If none of SUDO_EDITOR, VISUAL or EDITOR are set, the first program listed in the editor sudoers(5) option is used.
    3. If they've been modified, the temporary files get copied back to their original location and the temporary versions are removed 🧹.

To help stop people from editing files they shouldn't, these restrictions are enforced unless the security policy explicitly allows otherwise 🛡️:

  • Symbolic links may not be edited (version 1.8.15 and higher) 🚫.
  • Symbolic links along the path to be edited are not followed when the parent directory is writable by the invoking user, unless that user is root (version 1.8.16 and higher) 🔗.
  • Files located in a directory that is writable by the invoking user may not be edited unless that user is root (version 1.8.16 and higher) 📁.

Users are never allowed to edit device special files 🙅‍♀️.

If the specified file doesn't exist, it gets created ✨. Unlike most commands run by sudo, the editor runs with the invoking user's environment unmodified 🌷. If the temporary file is empty after editing, the user gets prompted before it's installed 🫣. If, for some reason, sudo can't update a file with its edited version, the user gets a warning and the edited copy stays in a temporary file 😬.

  • -g group, --group=group — runs the command with the primary group set to group instead of the primary group from the target user's password database entry 🎀. The group can be a group name or a numeric group-ID (GID) prefixed with the # character (e.g., #0 for GID 0). When running a command as a GID, many shells require that the # be escaped with a backslash (\) 🐚. If no -u option is given, the command runs as the invoking user. Either way, the primary group gets set to group 🔁. The sudoers policy lets you specify any of the target user's groups with -g as long as the -P option isn't in use 👯.
  • -H, --set-home — asks the security policy to set the HOME environment variable to the home directory from the target user's password database entry 🏠. Depending on the policy, this might be the default behavior already 🤷‍♀️.
  • -h, --help — displays a short help message to the standard output and exits 💁.
  • -h host, --host=host — runs the command on the specified host, if the security policy plugin supports remote commands 🌐. The sudoers plugin doesn't currently support running remote commands 🙅. This can also be used with the -l option to list a user's privileges for the remote host 📋.
  • -i, --login — runs the shell from the target user's password database entry as a login shell 🌙. That means login-specific resource files like .profile, .bash_profile, or .login will be read by the shell 📜. If a command is given, it's passed to the shell as a simple command using the -c option. The command and any args get concatenated, separated by spaces, after each character (including white space) is escaped with a backslash (\), except for alphanumerics, underscores, hyphens, and dollar signs 🧵. If no command is given, an interactive shell runs 🐚. sudo tries to change to that user's home directory before running the shell 🏡. The command runs with an environment similar to the one a user would get at login 🌸. Most shells behave differently when a command is specified versus an interactive session, so check your shell's manual for details 📖. The Command environment section in the sudoers(5) manual documents how -i affects the environment a command runs in when the sudoers policy is in use 💅.
  • -K, --remove-timestamp — similar to -k, except it removes every cached credential for the user, no matter the terminal or parent process ID 🧹. The next time sudo runs, a password must be entered if the security policy requires authentication 🔐. You can't use -K together with a command or any other option 🙅‍♀️. This option doesn't need a password 🫶. Not all security policies support credential caching, so this might not do anything for you 🤷‍♀️.
  • -k, --reset-timestamp — okay so, without a command this one wipes your cached credentials for the current session 🧹 Next time you run sudo in that session, you'll need to type your password if the security policy wants authentication. By default the sudoers policy keeps a separate cache record for each terminal (or the parent process ID if there's no terminal), so -k can't mess with sudo commands running in a different terminal session 🙈 See the timestamp_type option in sudoers(5) for more. This one doesn't need a password, and it was added so you can revoke sudo permissions from a .logout file 🚪

When you pair -k with a command or an option that might need a password, sudo ignores your cached credentials. So it'll prompt you for a password (if the security policy requires one) and won't update your cached credentials either. Main character move 💅

Not all security policies support credential caching.

  • -l, --list — list your privileges 📋 Without a command, this shows what the invoking user (or the user picked with -U) can do on the current host. If you specify it multiple times and the security policy supports verbose output, you get a longer list 👀

If you give a command that the policy allows for the invoking user (or the user picked with -U) on this host, sudo shows the fully-qualified path to the command along with any args. Use -l more than once (if the policy supports it) and the matching rule shows up in verbose format next to the command 🔍 If the command isn't allowed by the policy, sudo exits with a status value of 1. Big oof 💀

  • -N, --no-update — don't update the cached credentials, even if you authenticate successfully ✋ Unlike -k, existing cached credentials still get used if they're valid. To check whether your cached credentials are valid (or whether no authentication is needed at all), you can use:
sudo -Nnv

Not all security policies support credential caching.

  • -n, --non-interactive — no prompting, bestie 🤐 sudo won't ask you for any input of any kind. If the command needs a password, sudo displays an error message and exits instead.
  • -P, --preserve-groups — keeps your group vector exactly as it is 🫶 By default the sudoers policy resets the group vector to the list of groups the target user belongs to. The real and effective group-IDs still get set to match the target user, though.
  • -p prompt, --prompt=prompt — swap in a custom password prompt ✨ You can use these percent (%) escape sequences, which the sudoers policy supports:
    • %H — the full host name, domain included (only if the machine's host name is fully qualified or the fqdn option is set in sudoers(5)) 🌐
    • %h — the local host name, no domain 🏠
    • %p — the name of the user whose password is being requested (respects the rootpw, targetpw, and runaspw flags in sudoers(5)) 🔑
    • %U — the login name of the user the command will run as (defaults to root unless -u is also specified) 👑
    • %u — your invoking user's login name 🧁
    • %% — two % characters in a row collapse into a single % 💅

Your custom prompt overrides the default prompt from either the security policy or the SUDO_PROMPT environment variable. On systems that use PAM, it also overrides the prompt set by a PAM module, unless the passprompt_override flag is disabled in sudoers. 🎀

  • -R directory, --chroot=directory — change to the specified root directory (see chroot(8)) before running the command 🌳 The security policy might throw an error if you don't have permission to pick that root directory.
This option is deprecated and will be removed in a future version of sudo. Don't get too attached to it, bestie 😭
  • -r role, --role=role — run the command with an SELinux security context that includes the role you specify 🦋
  • -S, --stdin — the prompt goes to standard error, and the password gets read from standard input instead of the terminal device ⌨️ Handy for scripts 🧚
  • -s, --shell — run a shell 🐚 It uses the shell in the SHELL environment variable if that's set, or the shell from the invoking user's password database entry. If you give a command, it gets passed to the shell as a simple command using the -c option. The command and its args get joined with spaces, after every character (including white space) is escaped with a backslash (\), except for alphanumerics, underscores, hyphens, and dollar signs. If there's no command, you get an interactive shell ✨ Most shells act differently when a command is given versus an interactive session, so check your shell's manual for the deets 📖
  • -t type, --type=type — run the command with an SELinux security context that includes the type you specify 🌈 If you don't specify a type, the default type comes from the role.
  • -U user, --other-user=user — pairs with -l to list the privileges for user instead of for you 👀 The security policy might not let you peek at other users' privileges. With the sudoers policy, -U is limited to root and to users who have the "list" privilege for the specified user, or who can run any command as root or user on the current host 🔒
  • -T timeout, --command-timeout=timeout — set a timeout for the command ⏰ If the timeout runs out before the command exits, the command gets terminated 💀 The security policy might restrict your ability to set timeouts. The sudoers policy requires that user-specified timeouts be explicitly enabled.
  • -u user, --user=user — run the command as someone other than the default target user (usually root) 🧚 The user can be a user name or a numeric user-ID (UID) prefixed with the # character (e.g., #0 for UID 0). When running commands as a UID, many shells need the # escaped with a backslash (\) 🙈 Some security policies only allow UIDs that are in the password database. The sudoers policy allows UIDs that aren't in the password database, as long as the targetpw option isn't set. Other security policies might not support this at all.
  • -V, --version — prints the sudo version string, plus the version string of any configured plugins 🔢 If the invoking user is already root, -V also displays the options passed to configure when sudo was built. Plugins might show extra info, like default options 🤓
  • -v, --validate — update your cached credentials, authenticating you if needed ✅ For the sudoers plugin, this extends the sudo timeout by another 15 minutes by default, but it doesn't run a command. Not all security policies support cached credentials.
  • -- — the -- marks the end of the sudo options 🚧 Anything after it gets passed to the command.

Options that take a value can only be specified once, unless the description says otherwise 🙅‍♀️ This helps protect against problems caused by poorly written scripts that invoke sudo with user-controlled input. Protect yourself, babe 🛡️

You can also pass environment variables for the command as options to sudo, in the form VAR=value. For example: LD_LIBRARY_PATH=/usr/local/pkg/lib. These might be subject to restrictions from the security policy plugin ✨ The sudoers policy treats environment variables passed as options the same way as existing environment variables, with one important difference. If the setenv option is set in sudoers, and the command to be run has the SETENV tag set or the matched command is ALL, you can set variables that would otherwise be forbidden 👑 See sudoers(5) for more info.

✨ COMMAND EXECUTION ✨

okay so when sudo runs a command, the security policy decides the execution environment 💅 Usually the real and effective user and group IDs get set to match the target user from the password database, and the group vector gets set up from the group database (unless you passed -P) 🫶

the security policy can set any of these for the command:

  • real and effective user-ID 👑
  • real and effective group-ID 👑
  • supplementary group-IDs 🎀
  • the environment list 🌸
  • current working directory 📂
  • file creation mode mask (umask) 🦋
  • SELinux role and type 🔥
  • scheduling priority (aka nice value) ⭐

✨ Process model ✨

there are two distinct ways sudo can run a command, bestie 🧚

if an I/O logging plugin is set up to log terminal I/O, or the security policy explicitly asks for it, sudo allocates a new pseudo-terminal (“pty”) and calls fork(2) to make a second sudo process called the monitor 💜 the monitor creates a new terminal session where it's the leader and the pty is its controlling terminal, calls fork(2) again, sets up the execution environment as described above, and then uses the execve(2) system call to run the command in the child process 🦋 the monitor exists to relay job control signals between your terminal and the pty the command runs in, so you can suspend and resume the command like normal 🙌 without it, the command would be in what POSIX calls an “orphaned process group” and it would not get any job control signals from the kernel 💀 when the command exits or gets killed by a signal, the monitor passes the exit status up to the main sudo process and exits. then the main sudo process passes the exit status to the security policy's close function, plus the close function of any configured audit plugin, and exits 🌈 this mode is the default for sudo versions 1.9.14 and above when using the sudoers policy 💖

if no pty is used, sudo calls fork(2), sets up the execution environment as described above, and uses execve(2) to run the command in the child process 🌸 the main sudo process waits until the command finishes, then passes the exit status to the security policy's close function, plus the close function of any configured audit plugins, and exits ✨ as a special case, if the policy plugin doesn't define a close function, sudo just executes the command directly instead of calling fork(2) first 🙈 the sudoers policy plugin only defines a close function when I/O logging is enabled, a pty is required, an SELinux role is specified, the command has an associated timeout, or the pam_session or pam_setcred options are enabled. both pam_session and pam_setcred are enabled by default on systems using PAM 🫶 this mode is the default for sudo versions prior to 1.9.14 when using the sudoers policy 🍓

on systems that use PAM, the security policy's close function is responsible for closing the PAM session 🔐 it may also log the command's exit status 📝

✨ Signal handling ✨

when the command runs as a child of the sudo process, sudo relays any signals it receives over to the command 📡 SIGINT and SIGQUIT only get relayed when the command is running in a new pty, or when the signal was sent by a user process and not the kernel. this stops the command from getting SIGINT twice every time you hit control-C 🙄 some signals, like SIGSTOP and SIGKILL, can't be caught, so they won't be relayed to the command 💀 as a general rule, use SIGTSTP instead of SIGSTOP when you want to suspend a command being run by sudo 💜

as a special case, sudo won't relay signals that were sent by the command it's running. this stops the command from accidentally killing itself 😭 on some systems, the reboot(8) utility sends SIGTERM to all non-system processes other than itself before rebooting the system. this keeps sudo from relaying the SIGTERM it received back to reboot(8), which might then exit before the system was actually rebooted, leaving it in a half-dead state similar to single user mode 💀 heads up though, this check only applies to the command run by sudo and not to any other processes that command may create. so running a script that calls reboot(8) or shutdown(8) via sudo may leave the system in this undefined state, unless reboot(8) or shutdown(8) are run using the exec() family of functions instead of system() (which puts a shell between the command and the calling process) ⚠️

✨ Plugins ✨

plugins can be specified with Plugin directives in the sudo.conf(5) file 🧩 they may be loaded as dynamic shared objects (on systems that support them), or compiled directly into the sudo binary. if there's no sudo.conf(5) file, or it doesn't have any Plugin lines, sudo uses sudoers(5) for the policy, auditing, and I/O logging plugins 🎀 check the sudo.conf(5) manual for details on the /etc/sudo.conf file, and the sudo_plugin(5) manual for more info about the sudo plugin architecture 📚

✨ EXIT VALUE ✨

okay this part is so important 🥺 if a command runs successfully, the exit status from sudo is the exit status of the program that was executed 💯 if the command died from a signal, sudo sends itself the same signal that killed the command 💀

if you use the -l option without a command, sudo exits with 0 if you're allowed to run sudo and you authenticated successfully (as the security policy requires) ✅ if a command is given with -l, the exit value is only 0 if the security policy permits that command. otherwise it's 1 🙅‍♀️

if there's an authentication failure, a configuration or permission problem, or the given command can't be executed, sudo exits with 1 😭 in that last case, the error string gets printed to standard error. if sudo can't stat(2) one or more entries in your PATH, an error gets printed to standard error too. (if the directory doesn't exist or isn't really a directory, the entry gets ignored and no error is printed 🙈) this shouldn't happen under normal circumstances ✨ the most common reason stat(2) returns “permission denied” is if you're running an automounter and one of the directories in your PATH lives on a machine that's currently unreachable 🌐

✨ SECURITY NOTES ✨

sudo really tries to be safe when it executes external commands 🛡️

to prevent command spoofing, sudo checks "." and "" (both mean the current directory) last when it searches for a command in your PATH (if one or both are in there) 🕵️‍♀️ depending on the security policy, your PATH environment variable may be modified, replaced, or passed through unchanged to the program sudo runs 🫧

never give someone sudo privileges to run files that are writable by them, or that live in a directory they can write to 🚫 if the user can modify or replace the command, there's no way to limit what other commands they can run 💀

by default, sudo only logs the command it explicitly runs. if someone runs a command like sudo su or sudo sh, any commands run from that shell aren't subject to sudo's security policy 😱 the same goes for commands that offer shell escapes (including most editors) 📝 if I/O logging is enabled, those subsequent commands will have their input and/or output logged, but there won't be traditional logs for them. so be careful when you give users access to commands via sudo, and check that the command won't accidentally give them an effective root shell 👑 for ways to handle this, see the Preventing shell escapes section in sudoers(5) 📖

to protect potentially sensitive info, sudo disables core dumps by default while it's running (they get re-enabled for the command that runs) 🔒 this is a historical practice from a time when most operating systems let set-user-ID processes dump core by default 🦖 if you want to debug sudo crashes, you can re-enable core dumps by setting "disable_coredump" to false in the sudo.conf(5) file like this 🔧

    Set disable_coredump false

see the sudo.conf(5) manual for more info 🫶 💅

✨ ENVIRONMENT ✨

okay so sudo reads and sets a bunch of environment variables 🌸 but bestie, the security policy is the one with the final say on what the command's environment actually looks like 💅

  • EDITOR — the default editor for -e (sudoedit) mode, but only if neither SUDO_EDITOR nor VISUAL is set 📝
  • MAIL — gets set to the mail spool of the target user when you pass -i, or when env_reset is on in sudoers. (Unless MAIL is in the env_keep list, then it stays put 🫶)
  • HOME — gets set to the target user's home directory when you use -i or -H, when you use -s and set_home is set in sudoers, when always_set_home is enabled in sudoers, or when env_reset is enabled in sudoers and HOME isn't in the env_keep list 🏡
  • LOGNAME — gets set to the target user's login name when you use -i, when the set_logname option is enabled in sudoers, or when the env_reset option is enabled in sudoers (unless LOGNAME is in env_keep) 🎀
  • PATH — the security policy is allowed to override this one 🦋
  • SHELL — used to figure out which shell to run with the -s option 🐚
  • SUDO_ASKPASS — the path to a helper program that reads the password when there's no terminal around, or when you pass the -A option 🔐
  • SUDO_COMMAND — gets set to the command sudo ran, args included. The args get chopped off at 4096 characters to prevent a potential execution error 💀
  • SUDO_EDITOR — the default editor for -e (sudoedit) mode 📝
  • SUDO_GID — the group-ID of the person who invoked sudo 🌈
  • SUDO_HOME — the home directory of the person who invoked sudo 🏠
  • SUDO_PROMPT — the default password prompt, unless you used the -p option 💜
  • SUDO_PS1 — if this is set, PS1 gets set to its value for the program being run ⭐
  • SUDO_TTY — the terminal device of the person who invoked sudo, if there is one 🖥️
  • SUDO_UID — the user-ID of the person who invoked sudo 🧚
  • SUDO_USER — the login name of the person who invoked sudo 🍓
  • USER — set to the same value as LOGNAME, which we just covered 🫧
  • VISUAL — the default editor for -e (sudoedit) mode, but only if SUDO_EDITOR isn't set 🌷

✨ FILES ✨

okay this one's short and sweet 🍬

  • /etc/sudo.conf — the sudo front-end configuration 🔧

✨ EXAMPLES ✨

these examples assume your security policy is properly configured, so make sure that's sorted before you try them 🫶

To get a file listing of an unreadable directory:

$ sudo ls /usr/local/protected

To list the home directory of user yaz on a machine where the file system holding ~yaz is not exported as root:

$ sudo -u yaz ls ~yaz

To edit the index.html file as user www:

$ sudoedit -u www ~www/htdocs/index.html

To view system logs that only root and the users in the adm group can access:

$ sudo -g adm more /var/log/syslog

To run an editor as jim with a different primary group:

$ sudoedit -u jim -g audio ~jim/sound.txt

To shut down a machine:

$ sudo shutdown -r +15 "quick reboot"

To make a usage listing of the directories in the /home partition. The commands run in a sub-shell so that the ‘cd’ command and file redirection can actually work 🧠

$ sudo sh -c "cd /home ; du -s * | sort -rn > USAGE"

✨ DIAGNOSTICS ✨

here are the error messages sudo might throw at you, so you know what's going on when it happens 🙈

Error messages produced by sudo include:

editing files in a writable directory is not permitted

by default, sudoedit won't let you edit a file when any of the parent directories are writable by the user who invoked it. This avoids a race condition that could let the user overwrite an arbitrary file 🚫. See the sudoedit_checkdir option in sudoers(5) for more information.

by default, sudoedit doesn't follow symbolic links when it opens files 🔗. See the sudoedit_follow option in sudoers(5) for more information.

effective uid is not 0, is sudo installed setuid root?

sudo wasn't run with root privileges. The sudo binary has to be owned by the root user and have the set-user-ID bit set. It also can't be located on a file system mounted with the ‘nosuid’ option, or on an NFS file system that maps uid 0 to an unprivileged uid 😤

effective uid is not 0, is sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges?

sudo wasn't run with root privileges. The sudo binary has the right owner and permissions, but it still didn't run as root anyway 😭. The most common reason is that the file system the sudo binary lives on is mounted with the ‘nosuid’ option, or it's an NFS file system that maps uid 0 to an unprivileged uid.

fatal error, unable to load plugins

an error happened while loading or initializing the plugins specified in sudo.conf(5) 🔌

invalid environment variable name

one or more environment variable names you passed via the -E option had an equal sign (‘=’) in them. The arguments to -E should just be environment variable names, without any value attached 🙅‍♀️

no password was provided

when sudo tried to read the password, it didn't get any characters. This can happen when there's no terminal available (or you used the -S option) and standard input got redirected from /dev/null 🕳️

a terminal is required to read the password

sudo needs to read the password, but there's no mechanism available to do it. Remote commands run via ssh(1) don't have a terminal by default, but passing the -t option to ssh(1) makes it allocate one, which should let sudo read the password 💻. To let sudo run local commands without a terminal, you can use the -S option to read the password from standard input, or configure an askpass helper either through the sudo.conf(5) file or by setting the SUDO_ASKPASS environment variable 🔐.

no writable temporary directory found

sudoedit couldn't find a usable temporary directory to store its intermediate files 📂

The “no new privileges” flag is set, which prevents sudo from running as root.

sudo was run by a process that has the Linux “no new privileges” flag set. This makes the set-user-ID bit get ignored when running an executable, which stops sudo from working. The most likely cause is running sudo inside a container that sets this flag. Check the container's documentation to see if you can configure it so the flag isn't set 📦

sudo must be owned by uid 0 and have the setuid bit set

sudo wasn't run with root privileges. The sudo binary doesn't have the correct owner or permissions. It has to be owned by the root user and have the set-user-ID bit set 🛠️

sudoedit is not supported on this platform

sudoedit only works on systems that support setting the effective user-ID 🙃

timed out reading password

you didn't enter a password before the password timeout expired. That's 5 minutes by default ⏰

you do not exist in the passwd database

your user-ID doesn't show up in the system passwd database 👻

you may not specify environment variables in edit mode

you can only specify environment variables when you're running a command. When you're editing a file, the editor runs with your environment left completely unmodified 🙅

✨ SEE ALSO ✨

if you want to keep going, check these out 🦋

✨ HISTORY ✨

for a brief history of sudo, check out the HISTORY.md file in the sudo distribution, at https://www.sudo.ws/about/history/ 📜

✨ AUTHORS ✨

so many people have worked on sudo over the years 🫶 this version is made up of code written mainly by:

Todd C. Miller 👑

For an exhaustive list of everyone who's contributed to sudo, see the CONTRIBUTORS.md file in the sudo distribution, at https://www.sudo.ws/about/contributors/ 🌈

✨ CAVEATS ✨

okay real talk, these are the things you need to be careful about 🫣

There is no easy way to stop a user from getting a root shell if that user is allowed to run arbitrary commands via sudo 😬. Also, lots of programs (like editors) let you run commands through shell escapes, which means you can skip sudo's checks entirely. That said, on most systems you can block shell escapes with the noexec functionality in the sudoers(5) plugin 🔒.

It's not meaningful to run the ‘cd’ command directly via sudo, bestie, like this:

$ sudo cd /usr/local/protected

because when the command exits, the parent process (your shell) is still in the same directory it was before 🙃. The -D option can be used to run a command in a specific directory instead.

Running shell scripts via sudo can expose the same kernel bugs that make set-user-ID shell scripts unsafe on some operating systems. (If your OS has a /dev/fd/ directory, set-user-ID shell scripts are generally safe 🫧.)

✨ BUGS ✨

if you think you've found a bug in sudo, you can either file a report in the sudo bug database at https://bugzilla.sudo.ws/, or open an issue at https://github.com/sudo-project/sudo/issues 🐛. If you'd rather use email, you can send messages to the sudo-workers mailing list at https://www.sudo.ws/mailman/listinfo/sudo-workers (public), or to <sudo@sudo.ws> (private) 💌.

🚨 Please do NOT report security vulnerabilities through public GitHub issues, Bugzilla, or mailing lists! Instead, email them to <Todd.Miller@sudo.ws>. You can encrypt your message with PGP if you'd like, using the key found at https://www.sudo.ws/dist/PGPKEYS 🔐

✨ SUPPORT ✨

you can get limited free support through the sudo-users mailing list. Check https://www.sudo.ws/mailman/listinfo/sudo-users to subscribe or to search the archives 💬

✨ DISCLAIMER ✨

sudo is provided “AS IS”, and any express or implied warranties, including but not limited to the implied warranties of merchantability and fitness for a particular purpose, are disclaimed 🙅. For complete details, see the LICENSE.md file distributed with sudo, or https://www.sudo.ws/about/license/ 📄

That's a wrap on the sudo manual, bestie! 🎀 You made it through the whole thing, and honestly? Iconic behaviour 💅✨ Go touch grass, then go sudo responsibly 🫶🌸

📦 where this page comes from