Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
documentation.suse.com / Documentazione di SUSE Linux Enterprise Server / Administration Guide / Common Tasks / sudo
Applies to SUSE Linux Enterprise Server 12 SP5

2 sudo

Many commands and system utilities need to be run as root to modify files and/or perform tasks that only the super user is allowed to. For security reasons and to avoid accidentally running dangerous commands, it is generally advisable not to log in directly as root. Instead, it is recommended to work as a normal, unprivileged user and use the sudo command to run commands with elevated privileges.

On SUSE Linux Enterprise Server, sudo is configured by default to work similarly to su. However, sudo offers the possibility to allow users to run commands with privileges of any other user in a highly configurable manner. This can be used to assign roles with specific privileges to certain users and groups. It is for example possible to allow members of the group users to run a command with the privileges of wilber. Access to the command can be further restricted by, for example, forbidding to specify any command options. While su always requires the root password for authentication with PAM, sudo can be configured to authenticate with your own credentials. This increases security by not having to share the root password. For example, you can allow members of the group users to run a command frobnicate as wilber, with the restriction that no arguments are specified. This can be used to assign roles with specific abilities to certain users and groups.

2.1 Basic sudo Usage

sudo is simple to use, yet very powerful.

2.1.1 Running a Single Command

Logged in as normal user, you can run any command as root by adding sudo before it. It will prompt for the root password and, if authenticated successfully, run the command as root:

tux > id -un1
tux > sudo id -un
root's password:2
tux > id -un
tux > sudo id -un


The id -un command prints the login name of the current user.


The password is not shown during input, neither as clear text nor as bullets.


Only commands started with sudo are run with elevated privileges. If you run the same command without the sudo prefix, it is run with the privileges of the current user again.


The elevated privileges persist for a certain period of time, so you do not need to provide the root password again.

Tip: I/O Redirection

I/O redirection does not work as you would probably expect:

tux > sudo echo s > /proc/sysrq-trigger
bash: /proc/sysrq-trigger: Permission denied
tux > sudo cat < /proc/1/maps
bash: /proc/1/maps: Permission denied

Only the echo/cat binary is run with elevated privileges, while the redirection is performed by the user's shell with user privileges. You can either start a shell like in Section 2.1.2, “Starting a Shell” or use the dd utility instead:

echo s | sudo dd of=/proc/sysrq-trigger
sudo dd if=/proc/1/maps | cat

2.1.2 Starting a Shell

Having to add sudo before every command can be cumbersome. While you could specify a shell as a command sudo bash, it is recommended to rather use one of the built-in mechanisms to start a shell:

sudo -s (<command>)

Starts a shell specified by the SHELL environment variable or the target user's default shell. If a command is given, it is passed to the shell (with the -c option), else the shell is run in interactive mode.

tux:~ > sudo -i
root's password:
root:/home/tux # exit
tux:~ > 
sudo -i (<command>)

Like -s, but starts the shell as login shell. This means that the shell's start-up files (.profile etc.) are processed and the current working directory is set to the target user's home directory.

tux:~ > sudo -i
root's password:
root:~ # exit
tux:~ > 

2.1.3 Environment Variables

By default, sudo does not propagate environment variables:

tux > ENVVAR=test env | grep ENVVAR
tux > ENVVAR=test sudo env | grep ENVVAR
root's password:
tux > 


The empty output shows that the environment variable ENVVAR did not exist in the context of the command run with sudo.

This behavior can be changed by the env_reset option, see Table 2.1, “Useful Flags and Options”.

2.2 Configuring sudo

sudo is a very flexible tool with extensive configuration.

Note: Locked yourself out of sudo

If you accidentally locked yourself out of sudo, use su - and the root password to get a root shell. To fix the error, run visudo.

2.2.1 Editing the Configuration Files

The main policy configuration file for sudo is /etc/sudoers. As it is possible to lock yourself out of the system due to errors in this file, it is strongly recommended to use visudo for editing. It will prevent simultaneous changes to the opened file and check for syntax errors before saving the modifications.

Despite its name, you can also use editors other than vi by setting the EDITOR environment variable, for example:

sudo EDITOR=/usr/bin/nano visudo

However, the /etc/sudoers file itself is supplied by the system packages and modifications may break on updates. Therefore, it is recommended to put custom configuration into files in the /etc/sudoers.d/ directory. Any file in there is automatically included. To create or edit a file in that subdirectory, run:

sudo visudo -f /etc/sudoers.d/NAME

Alternatively with a different editor (for example nano):

sudo EDITOR=/usr/bin/nano visudo -f /etc/sudoers.d/NAME
Note: Ignored Files in /etc/sudoers.d

The #includedir command in /etc/sudoers, used for /etc/sudoers.d, ignores files that end in ~ (tilde) or contain a . (dot).

For more information on the visudo command, run man 8 visudo.

2.2.2 Basic sudoers Configuration Syntax

In the sudoers configuration files, there are two types of options: strings and flags. While strings can contain any value, flags can be turned either ON or OFF. The most important syntax constructs for sudoers configuration files are:

# Everything on a line after a # gets ignored 1
Defaults !insults # Disable the insults flag 2
Defaults env_keep += "DISPLAY HOME" # Add DISPLAY and HOME to env_keep
tux ALL = NOPASSWD: /usr/bin/frobnicate, PASSWD: /usr/bin/journalctl 3


There are two exceptions: #include and #includedir are normal commands. Followed by digits, it specifies a UID.


Remove the ! to set the specified flag to ON.


See Section 2.2.3, “Rules in sudoers”.

Table 2.1: Useful Flags and Options

Option name




This flag controls whether the invoking user is required to enter the password of the target user (ON) (for example root) or the invoking user (OFF).

Defaults targetpw # Turn targetpw flag ON

If set, sudo will prompt for the root password instead of the target user's or the password of the user that invoked the command. The default is OFF.

Defaults !rootpw # Turn rootpw flag OFF

If set, sudo constructs a minimal environment with only TERM, PATH, HOME, MAIL, SHELL, LOGNAME, USER, USERNAME, and SUDO_* set. Additionally, variables listed in env_keep get imported from the calling environment. The default is ON.

Defaults env_reset # Turn env_reset flag ON

List of environment variables to keep when the env_reset flag is ON.

# Set env_keep to contain EDITOR and PROMPT
Defaults env_keep = "EDITOR PROMPT"
Defaults env_keep += "JRE_HOME" # Add JRE_HOME
Defaults env_keep -= "JRE_HOME" # Remove JRE_HOME

List of environment variables to remove when the env_reset flag is OFF.

# Set env_delete to contain EDITOR and PROMPT
Defaults env_delete = "EDITOR PROMPT"
Defaults env_delete += "JRE_HOME" # Add JRE_HOME
Defaults env_delete -= "JRE_HOME" # Remove JRE_HOME

The Defaults token can also be used to create aliases for a collection of users, hosts, and commands. Furthermore, it is possible to apply an option only to a specific set of users.

For detailed information about the /etc/sudoers configuration file, consult man 5 sudoers.

2.2.3 Rules in sudoers

Rules in the sudoers configuration can be very complex, so this section will only cover the basics. Each rule follows the basic scheme ([] marks optional parts):

#Who      Where         As whom      Tag                What
User_List Host_List = [(User_List)] [NOPASSWD:|PASSWD:] Cmnd_List
Syntax for sudoers Rules

One or more (separated by ,) identifiers: Either a user name, a group in the format %GROUPNAME or a user ID in the format #UID. Negation can be performed with a ! prefix.


One or more (separated by ,) identifiers: Either a (fully qualified) host name or an IP address. Negation can be performed with a ! prefix. ALL is the usual choice for Host_List.


The user will not be prompted for a password when running commands matching CMDSPEC after NOPASSWD:.

PASSWD is the default, it only needs to be specified when both are on the same line:

tux ALL = PASSWD: /usr/bin/foo, NOPASSWD: /usr/bin/bar

One or more (separated by ,) specifiers: A path to an executable, followed by allowed arguments or nothing.

/usr/bin/foo     # Anything allowed
/usr/bin/foo bar # Only "/usr/bin/foo bar" allowed
/usr/bin/foo ""  # No arguments allowed

ALL can be used as User_List, Host_List, and Cmnd_List.

A rule that allows tux to run all commands as root without entering a password:


A rule that allows tux to run systemctl restart apache2:

tux ALL = /usr/bin/systemctl restart apache2

A rule that allows tux to run wall as admin with no arguments:

tux ALL = (admin) /usr/bin/wall ""
Warning: Dangerous constructs

Constructs of the kind


must not be used without Defaults targetpw, otherwise anyone can run commands as root.

Important: Winbind and sudo

When specifying the group name in the sudoers file, make sure that you use the the NetBIOS domain name instead of the realm, for example:


Keep in mind that when using winbindd, the format also depends on the winbind separator option in the smb.conf file. By default, it is \. If it is changed, for example, to +, then the account format in sudoers file must be DOMAIN+GROUP_NAME.

2.3 Common Use Cases

Although the default configuration is often sufficient for simple setups and desktop environments, custom configurations can be very useful.

2.3.1 Using sudo without root password

By design, members of the group wheel can run all commands with sudo as root. The following procedure explains how to add a user account to the wheel group.

  1. Verify that the wheel group exists:

    tux > getent group wheel

    If the previous command returned no result, install the system-group-wheel package that creates the wheel group:

    tux > sudo zypper install system-group-wheel
  2. Add your user account to the group wheel.

    If your user account is not already a member of the wheel group, add it using the sudo usermod -a -G wheel USERNAME command. Log out and log in again to enable the change. Verify that the change was successful by running the groups USERNAME command.

  3. Authenticate with the user account's normal password.

    Create the file /etc/sudoers.d/userpw using the visudo command (see Section 2.2.1, “Editing the Configuration Files”) and add the following:

    Defaults !targetpw
  4. Select a new default rule.

    Depending on whether you want users to re-enter their passwords, uncomment the specific line in /etc/sudoers and comment out the default rule.

    ## Uncomment to allow members of group wheel to execute any command
    # %wheel ALL=(ALL) ALL
    ## Same thing without a password
    # %wheel ALL=(ALL) NOPASSWD: ALL
  5. Make the default rule more restrictive

    Comment out or remove the allow-everything rule in /etc/sudoers:

    ALL     ALL=(ALL) ALL   # WARNING! Only use this together with 'Defaults targetpw'!
    Warning: Dangerous rule in sudoers

    Do not forget this step, otherwise any user can execute any command as root!

  6. Test the configuration

    Try to run sudo as member and non-member of wheel.

    tux:~ > groups
    users wheel
    tux:~ > sudo id -un
    tux's password:
    wilber:~ > groups
    wilber:~ > sudo id -un
    wilber is not in the sudoers file.  This incident will be reported.

2.3.2 Using sudo with X.Org Applications

When starting graphical applications with sudo, you will encounter the following error:

tux > sudo xterm
xterm: Xt error: Can't open display: %s
xterm: DISPLAY is not set

YaST will pick the ncurses interface instead of the graphical one.

To use X.Org in applications started with sudo, the environment variables DISPLAY and XAUTHORITY need to be propagated. To configure this, create the file /etc/sudoers.d/xorg, (see Section 2.2.1, “Editing the Configuration Files”) and add the following line:

Defaults env_keep += "DISPLAY XAUTHORITY"

If not set already, set the XAUTHORITY variable as follows:

export XAUTHORITY=~/.Xauthority

Now X.Org applications can be run as usual:

sudo yast2

2.4 More Information

A quick overview about the available command line switches can be retrieved by sudo --help. An explanation and other important information can be found in the man page: man 8 sudo, while the configuration is documented in man 5 sudoers.