Sudo

Related articles
doas
run0
su
Users and groups
Privilege elevation for graphical applications
Sudo
allows a system administrator to delegate authority to give certain users—or groups of users—the ability to run commands as root or another user while providing an audit trail of the commands and their arguments.
Sudo is an alternative to
su
for running commands as root. Unlike
su
, which launches a root shell that allows all further commands root access, sudo instead grants temporary privilege elevation to a single command. By enabling root privileges only when needed, sudo usage reduces the likelihood that a typo or a bug in an invoked command will ruin the system.
Sudo can also be used to run commands as other users; additionally, sudo logs all commands and failed access attempts to the
journal
for security auditing.
Installation
Install
the
sudo
package.
Alternatively, install the
sudo-rs
package, which is a memory-safe implementation of
sudo
, albeit with
some limitations
.
Usage
To begin using
sudo
as a non-privileged user, it must be properly configured. See
#Configuration
.
To use
sudo
, simply prefix a command and its arguments with
sudo
and a space:
$ sudo
cmd
For example, to use pacman:
$ sudo pacman -Syu
See
sudo(8)
for more information.
Login shell
You cannot run every command as an other user simply by prepending
sudo
. In particular when using a
redirection
and
command substitution
, you must use a login shell, which can be easily accessed with
sudo -iu
user
(one can omit
-u
user
if the desired user is root).
In the following example command substitution would work in a full shell, but fails with prepending
sudo
:
$ sudo wpa_supplicant -B -i
interface
-c
<(
wpa_passphrase
MYSSID passphrase
)
Successfully initialized wpa_supplicant
Failed to open config file '/dev/fd/63', error: No such file or directory
Failed to read or parse configuration '/dev/fd/63'
Configuration
The main configuration file for sudo is
/etc/sudoers
. It should
always
be edited with the
visudo(8)
command. It can be used to set aliases (basically variables), change default behaviors and specify which users may run what. See
sudoers(5)
for more information.
sudo
also parses files contained in the directory
/etc/sudoers.d/
. This means that instead of editing
/etc/sudoers
, you can change settings in standalone files and drop them in that directory. This has two advantages:
There is no need to merge the
sudoers.pacnew
file;
If there is a problem with a new entry, you can remove the offending file instead of editing
/etc/sudoers
(but see the warning below).
The format for entries in these drop-in files is the same as for
/etc/sudoers
itself. To edit them directly, use
visudo /etc/sudoers.d/
somefile
. See
sudoers(5) § Including other files from within sudoers
for details.
The files in
/etc/sudoers.d/
directory are parsed in lexicographical order, file names containing
.
or
~
are skipped. To avoid sorting problems, the file names should begin with two digits, e.g.
10-foo
.
Note
The order of entries in the drop-in files is important: make sure that the statements do not override themselves.
Warning
The files in
/etc/sudoers.d/
are just as fragile as
/etc/sudoers
itself: any improperly formatted file will prevent
sudo
from working.  Hence, for the same reason it is strongly advised to use
visudo
.
Defaults skeleton
As explained in
sudoers(5) § Defaults
, many behavioral "configuration options may be changed from their default values at run-time via one or more
Default_Entry
lines".
sudoers(5) § SUDOERS OPTIONS
lists all the options that can be used with the
Defaults
command in the configuration.
View current settings
Run
sudo -ll
to print out the current sudo configuration, or
sudo -lU
user
for a specific user.
Using visudo
visudo
locks the specified file (
/etc/sudoers
by default), saves edits to a temporary file, and checks it for syntax errors before writing it.
Warning
It is imperative that
sudoers
be free of syntax errors! Any error makes sudo unusable.
Always
edit it with
visudo
to prevent errors.
visudo(8)
warns that configuring
visudo
to honor the user environment variables for their editor of choice may be a security hole, since it allows the user with
visudo
privileges to run arbitrary commands as root without logging simply by setting that variable to something else.
The default editor for
visudo
is
vi
. The
sudo
package is compiled with
--with-env-editor
and honors the use of the
SUDO_EDITOR
,
VISUAL
and
EDITOR
variables.
EDITOR
is not used when
VISUAL
is set.
To establish
nano
as the
visudo
editor for the duration of the current shell session, export
EDITOR=nano
; to use a different editor just once simply set the variable before calling
visudo
:
# EDITOR=nano visudo /etc/sudoers.d/10-editor
To change the editor permanently, see
Environment variables#Per user
.
To change the editor permanently system-wide only for
visudo
(for example with
rnano(1)
,
nano
's restricted mode):
/etc/sudoers.d/10-editor
# Set default EDITOR to restricted version of nano, and do not allow visudo to use EDITOR/VISUAL.
Defaults      editor=/usr/bin/rnano, !env_editor
Alternatively you may edit a copy of the file and check it afterwards using
visudo -c
/copy/of/file
. This might come in handy in case you want to circumvent locking the file with
visudo
.
Example entries
To allow—when they precede a command with
sudo
—the
archie
user to run on a single machine (
hostname
) as any user and group all commands, create:
/etc/sudoers.d/90-archie
archie
hostname
=(ALL:ALL) ALL
To allow members of group
wheel
all access:
/etc/sudoers.d/10-wheel
%wheel      ALL=(ALL:ALL) ALL
Tip
When creating new administrators, it is often desirable to enable sudo access for the
wheel
group and
add the user to it
, since by default
Polkit
treats the members of the
wheel
group as administrators. If the user is not a member of
wheel
, software using Polkit may ask to authenticate using the root password instead of the user password.
To disable asking for a password for user
archie
:
Warning
This will allow any process running with your user name to use sudo without asking for permission.
/etc/sudoers.d/90-archie_nopasswd
Defaults:archie      !authenticate
Enable explicitly defined commands only for user
archie
on
hostname
without password:
/etc/sudoers.d/90-archie_commands
archie
hostname
= NOPASSWD: /usr/bin/halt,/usr/bin/poweroff,/usr/bin/reboot,/usr/bin/pacman -Syu
Note
The most customized option should go at the end of the file (or use a file name late in the lexicographical order for drop-in files), as the later lines overrides the previous ones. In particular such a line should be after the
%wheel
line if your user is in this group.
A detailed
sudoers
example is available at
/usr/share/doc/sudo/examples/sudoers
. Otherwise, see the
sudoers(5)
for detailed information.
Sudoers default file permissions
The owner and group for the
sudoers
file must both be 0. The file permissions must be set to 0440. These permissions are set by default, but if you accidentally change them, they should be changed back immediately or sudo will fail.
# chown -c root:root /etc/sudoers
# chmod -c 0440 /etc/sudoers
Running a command via SSH
SSH does not allocate a tty by default when running a remote command. Without an allocated tty, sudo cannot prevent the password from being displayed. You should use ssh's
-t
option to force it to allocate a tty and set the
Defaults
option
requiretty
to only allows the user to run sudo if they have a tty.
/etc/sudoers.d/10-requiretty
# Disable "ssh hostname sudo <cmd>", because it will show the password in clear text. You have to run "ssh -t hostname sudo <cmd>".
#
Defaults    requiretty
Defaults    cmddenial_message="Usage without a TTY is not allowed: run 'ssh -t'!"
Permissive umask
Sudo will union the user's
umask
value with its own umask (which defaults to 0022). This prevents sudo from creating files with more open permissions than the user's umask allows. While this is a sane default if no custom umask is in use, this can lead to situations where a utility run by sudo may create files with different permissions than if run by root directly. If errors arise from this, sudo provides a means to fix the umask, even if the desired umask is more permissive than the umask that the user has specified:
/etc/sudoers.d/10-umask_override
Defaults umask = 0022
Defaults umask_override
This sets sudo's umask to root's default umask (0022) and overrides the default behavior, always using the indicated umask regardless of what umask the user as set.
Tips and tricks
Reduce the number of times you have to type a password
If you are annoyed that you have to re-enter your password every 5 minutes (default), you can change this by setting a longer value for
timestamp_timeout
(in minutes):
/etc/sudoers.d/10-timestamp_timeout
Defaults timestamp_timeout=10
If you are using sudo commands in a long script and you do not want to wait for user input when the timeout expires, it is possible to refresh the timeout by separately running
sudo -v
in a loop (whereas
sudo -K
revokes it immediately).
Disable password prompt timeout
A common annoyance is a long-running process that runs on a background terminal somewhere that runs with normal permissions and elevates only when needed. This leads to a sudo password prompt which goes unnoticed and times out, at which point the process dies and the work done is lost or, at best, cached. Common advice is to enable passwordless sudo, or extend the timeout of sudo remembering a password. Both of these have negative security implications. The
prompt
timeout can also be disabled and since that does not serve any reasonable security purpose it should be the solution here:
/etc/sudoers.d/10-passwd_timeout
Defaults passwd_timeout=0
Passing aliases
The following is only relevant if the bash completion is not available (either full or reduced as described above): Aliases in
Zsh
and
Bash
are normally only expanded for the first word in a command. This means that your aliases will not normally get expanded when running the
sudo
command. One way to make the next word expand is to make an alias for sudo ending with a space. Add the following to your
shell's configuration file
:
alias sudo='sudo '
zshmisc(1) § ALIASING
describes how this works:
If the replacement text ends with a space, the next word in the shell input is always eligible for purposes of alias expansions.
As well as
bash(1) § ALIASES
:
If the last character of the alias value is a blank, then the next command word following the alias is also checked for alias expansion.
Add terminal bell to the password prompt
To draw attention to a sudo prompt in a background terminal, users can simply make it echo a
bell character
:
/etc/sudoers.d/10-passprompt
Defaults passprompt="
^G
[sudo] password for %p: "
Note the
^G
is a literal bell character. E.g. in
vim
, insert using the sequence
Ctrl+v
Ctrl+g
. If
Ctrl+v
is mapped, e.g. for pasting, one can
usually
use
Ctrl+q
instead. In
nano
,
Alt+v
Ctrl+g
.
Another option is to set the
SUDO_PROMPT
environment variable
. For example, add the following to your shell configuration file:
export SUDO_PROMPT=$'\a[sudo] password for %p: '
An alternative that allows keeping the localized prompt is to add an alias to your
shell's configuration file
:
alias sudo='sudo -B'
Disable per-terminal sudo
If you are annoyed by sudo's defaults that require you to enter your password every time you open a new terminal, change the
timestamp_type
(which is
tty
by default) to
ppid
so that all processes with the same parent process ID will share the 5 minutes timeout. This is particularly useful with a
terminal multiplexer
or tabbed graphical terminal emulators. An other option is to set it to
global
.
Warning
Having a
global
timestamp will let any process use your sudo session.
/etc/sudoers.d/10-timestamp_type
Defaults timestamp_type=ppid
Environment variables
If you have a lot of environment variables, or you export your proxy settings via
export http_proxy="..."
, when using sudo these variables do not get passed to the root account unless you run sudo with the
-E
/
--preserve-env
option.
$ sudo -E pacman -Syu
The recommended way of preserving environment variables is to append them to
env_keep
:
/etc/sudoers.d/10-env_keep
Defaults env_keep += "ftp_proxy http_proxy https_proxy no_proxy"
Root password
Users can configure sudo to ask for the root password instead of the user password by adding
targetpw
(target user, defaults to root) or
rootpw
to the Defaults line in
/etc/sudoers
:
/etc/sudoers.d/10-targetpw
Defaults targetpw
To prevent exposing your root password to users, you can restrict this to a specific group:
/etc/sudoers.d/10-targetpw
Defaults:%wheel targetpw
%wheel ALL=(ALL) ALL
Disable root login
Users may wish to disable the root login. Without root, attackers must first guess a user name configured as a sudoer as well as the user password. See for example
OpenSSH#Deny
.
Warning
Be careful, you may lock yourself out by disabling root login. Sudo is not automatically installed and its default configuration allows neither passwordless root access nor root access with your own password. Ensure a user is properly configured as a sudoer
before
disabling the root account!
If you have changed your sudoers file to use rootpw as default, then do not disable root login with any of the following commands!
If you are already locked out, see
Password recovery
for help.
The account can be locked via
passwd
:
# passwd -l root
A similar command unlocks root.
$ sudo passwd -u root
Alternatively, you can use the following command to delete the password and then lock the root account :
$ sudo passwd -dl root
To enable root login again:
$ sudo passwd root
Note that this merely disables password-based login. The user may still be able to login using another authentication token (e.g. an SSH key). To disable the account use:
$ usermod --expiredate 1 root
The factual accuracy of this article or section is disputed.
Reason:
In most cases when a user ends up in an emergency shell they are using the initramfs, will not use the following configuration, unless added to the
FILES
in
mkinitcpio's configuration
. (Discuss in
Talk:Sudo
)
In case of system emergency, the recovery prompt is going to ask you for a root password, making it impossible to log into recovery shell. To automatically unlock the root account in case of emergency add
SYSTEMD_SULOGIN_FORCE=1
environment variable to
rescue.service
using a
drop-in file
:
/etc/systemd/system/rescue.service.d/SYSTEMD_SULOGIN_FORCE.conf
[Service]
Environment=SYSTEMD_SULOGIN_FORCE=1
Tip
To get to an interactive root prompt, even after disabling the
root
account, use
sudo -i
.
kdesu
kdesu may be used under
KDE
to launch GUI applications with root privileges. It is possible that by default kdesu will try to use su even if the root account is disabled. Fortunately one can tell kdesu to use sudo instead of su. Create/edit the file
~/.config/kdesurc
:
[super-user-command]
super-user-command=sudo
or use the following command:
$ kwriteconfig6 --file kdesurc --group super-user-command --key super-user-command sudo
Harden with sudo example
Let us say you create 3 users: admin, devel, and archie. The user "admin" is used for journalctl, systemctl, mount, kill, and iptables; "devel" is used for installing packages, and editing configuration files; and "archie" is the user you log in with. To let "archie" reboot, shutdown, and use netctl we would do the following:
Edit
/etc/pam.d/su
and
/etc/pam.d/su-l
. Require user be in the wheel group, but do not put anyone in it.
#%PAM-1.0
auth            sufficient      pam_rootok.so
# Uncomment the following line to implicitly trust users in the "wheel" group.
#auth           sufficient      pam_wheel.so trust use_uid
# Uncomment the following line to require a user to be in the "wheel" group.
auth            required        pam_wheel.so use_uid
auth            required        pam_unix.so
account         required        pam_unix.so
session         required        pam_unix.so
Limit SSH login to the 'ssh' group. Only
archie
will be part of this group.
# groupadd -r ssh
# gpasswd -a archie ssh
# echo 'AllowGroups ssh' >> /etc/ssh/sshd_config
Restart
sshd.service
.
Add users to other groups.
# for g in power network ;do ;gpasswd -a archie $g ;done
# for g in network power storage ;do ;gpasswd -a admin $g ;done
Set permissions on configuration files so
devel
can edit them.
# chown -R devel:root /etc/{http,openvpn,cups,zsh,vim,screenrc}
/etc/sudoers.d/80-hardened
Cmnd_Alias  POWER       =   /usr/bin/shutdown -h now, /usr/bin/halt, /usr/bin/poweroff, /usr/bin/reboot
Cmnd_Alias  STORAGE     =   /usr/bin/mount -o nosuid\,nodev\,noexec, /usr/bin/umount
Cmnd_Alias  SYSTEMD     =   /usr/bin/journalctl, /usr/bin/systemctl
Cmnd_Alias  KILL        =   /usr/bin/kill, /usr/bin/killall
Cmnd_Alias  PKGMAN      =   /usr/bin/pacman
Cmnd_Alias  NETWORK     =   /usr/bin/netctl
Cmnd_Alias  FIREWALL    =   /usr/bin/iptables, /usr/bin/ip6tables
Cmnd_Alias  SHELL       =   /usr/bin/zsh, /usr/bin/bash
%power      ALL         =   (root)  NOPASSWD: POWER
%network    ALL         =   (root)  NETWORK
%storage    ALL         =   (root)  STORAGE
root        ALL         =   (ALL)   ALL
admin       ALL         =   (root)  SYSTEMD, KILL, FIREWALL
devel	    ALL         =   (root)  PKGMAN
archie	    ALL         =   (devel) SHELL, (admin) SHELL
With this setup, you will almost never need to login as the root user.
archie
can connect to their home Wi-Fi.
$ sudo netctl start home
$ sudo poweroff
archie
can not use netctl as any other user.
$ sudo -u admin -- netctl start home
When
archie
needs to use journalctl or kill run away process they can switch to that user.
$ sudo -i -u devel
$ sudo -i -u admin
But
archie
cannot switch to the root user.
$ sudo -i -u root
If
archie
want to start a
GNU Screen
session as admin they can do it like this:
$ sudo -i -u admin
[admin]$ chown admin:tty `echo $TTY`
[admin]$ screen
Editing files
sudo
provides the
sudoedit
command (equivalent to
sudo -e
). This is useful for editing files which can be edited by root only while still running the editor as a normal user, and using that user’s configuration.
To edit a file, set
SUDO_EDITOR
to the name of the editor and pass the file name to
sudoedit
. For example:
$ SUDO_EDITOR=vim sudoedit /etc/file
See
#Using visudo
and
sudo(8) § e
for ways to set the editor, but beware of
possible security issues
.
If multiple names are passed to
sudo
, all files are opened in the editor in a single invocation. A feature useful for merging files:
$ SUDO_EDITOR=vimdiff sudoedit /etc/file /etc/file.pacnew
Enable insults
Users can enable the insults easter egg in sudo by adding the following line in the
sudoers
file with
visudo
.
/etc/sudoers.d/10-insults
Defaults insults
Upon entering an incorrect password, this will replace
Sorry, try again.
message with humorous insults.
Enable password input feedback
By default, there is no visual feedback when you input a password. That is done on purpose for extra security. However, if you wish to have visual input, you can enable it by adding this line:
/etc/sudoers.d/10-pwfeedback
Defaults pwfeedback
Colored password prompt
To customize the password prompt with colors and/or bold fonts, set the
SUDO_PROMPT
environment variable
in your shell initialization file and use
tput(1)
.
For example, to set the password prompt to display
Password:
in bold red, use this:
export SUDO_PROMPT="$(tput setaf 1 bold)Password:$(tput sgr0) "
Or use different colors with the default message like so:
export SUDO_PROMPT="$(tput setab 1 setaf 7 bold)[sudo]$(tput sgr0) $(tput setaf 6)password for$(tput sgr0) $(tput setaf 5)%p$(tput sgr0): "
See more on
Color output in console
and
Bash/Prompt customization
Using U2F
U2F is great to use with sudo, as it can effectively eliminate the risk of
shoulder surfing
in public areas while still giving you conscious control to approve the prompt with a simple physical touch.
See
Universal 2nd Factor#Passwordless sudo
.
Write to protected files
When using sudo, you may want to write to protected files. Using
tee
allows such a separation:
$
input stream
| sudo tee
--option
protected_file_1 protected_file_2...
when a simple
>
/
>>
would not have worked.
In Vim
A similar concept is useful when you forgot to start
Vim
with sudo when editing a file owned by an other user. In this case you can do the following inside
Vim
to save the file:
:w !sudo tee %
You can add this to your
~/.vimrc
to make this trick easy-to-use with
:w!!
mapping in command mode:
~/.vimrc
" Allow saving of files as sudo when I forgot to start vim using sudo
 cmap w!! w !sudo tee > /dev/null %
The
> /dev/null
part explicitly throws away the standard output since we do not need to pass anything to another piped command.
More detailed explanation of how and why this works can be found in
How does the vim “write with sudo” trick work?
article on StackOverflow.
Using sudo-rs without the sudo package
You can use
sudo-rs
as a standalone replacement for
sudo
, without requiring the
sudo
package.
Create
/etc/pam.d/sudo
following
sudo
's
default configuration
.
Also create
/etc/pam.d/sudo-i
for
sudo -i
:
# ln -s /etc/pam.d/sudo /etc/pam.d/sudo-i
sudo-rs
supports both
/etc/sudoers
and
/etc/sudoers-rs
and uses the latter if it exists. Create at least one of these. A valid minimal config could be this:
This article or section is being considered for removal.
Reason:
A config snippet here should not be needed, users can either write their own or copy
sudo
's config. (Discuss in
Talk:Sudo
)
/etc/sudoers-rs
# Keep your editor when running visudo
Defaults!/usr/bin/visudo-rs env_keep += "SUDO_EDITOR EDITOR VISUAL"
# The same if you choose to symlink visudo-rs to visudo
Defaults!/usr/local/bin/visudo env_keep += "SUDO_EDITOR EDITOR VISUAL"

# Sanitize your path
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/bin"

# "root", and all members of the group "wheel" can run any command after providing a password.
root ALL=(ALL:ALL) ALL
%wheel ALL=(ALL:ALL) ALL
Optionally, you can replace
sudo
with
sudo-rs
by symlinking it from a higher priority
PATH
directory:
# ln -s /usr/bin/sudo-rs /usr/local/bin/sudo
# ln -s /usr/bin/su-rs /usr/local/bin/su
# ln -s /usr/bin/visudo-rs /usr/local/bin/visudo
# ln -s /usr/bin/sudoedit-rs /usr/local/bin/sudoedit