Configuring Superuser Privileges with sudo

Before your start, here are a few ground rules for maintaining sudo configurations:

Tip: sudo configuration and immutable file systems

An immutable file system is a file system that cannot be changed once it has been installed. It is accessed read-only. If the SUSE product you are using relies on an immutable file system, the sudo default configuration shipped with the product is installed under /usr/etc/sudoers and any pre-configured adjustments reside under /usr/etc/sudoers.d/.

Your own custom configurations are located under /etc/sudoers.d/ and take precedence over anything that is provided in /usr/etc/sudoers.d/. The visudo command opens /usr/etc/sudoers and saves the changed file to /etc/sudoers, if there was no prior sudoers file. If there was already one, visudo opens and writes that one. The instance located under /etc/ takes precedence over the one that is kept under /usr/etc/. This way, user-made configuration adjustments will not get broken upon updates.

Create a sudo configuration file that allows a normal user (tux) to use the useradd command with their own password instead of the root password.

Modify the configuration from Example 1, “Create a user-specific configuration file” so that a group of named users can run the useradd command without the need for the root password. Also, add the usermod and userdel to the list of commands available to this group.

Use aliases to simplify your custom configuration from Example 2, “Create custom configurations by grouping items” even further. Grouping items helps to a certain extent, but using global aliases for users, commands and hosts is the most efficient way to keep a clean and lean sudo configuration.

Using aliases and groups instead of lists is a much better way to address changes in your setup. Should a user leave, just remove them from the global User_Alias declaration in your alias declaration file instead of scouring all the separate custom configuration files. The same procedure applies for any other type of alias (Host_Alias, Cmnd_Alias and Runas_Alias).

Note: For more information

Find a more detailed description of the sudo configuration syntax in Section 7, “sudo configuration reference” and refer to the man page of sudo.

Having to enter sudo every time you want to run a command as root can become tedious. Instead, you can use one of the built-in mechanisms to start a shell with permanent root privileges. For this, there are two command options available:

With both commands, the shell is started with a new environment, and you are logged in as root. Any subsequent command that is executed within that shell is run with elevated privileges without having to enter the password again. This environment is terminated when you close the shell, and you must enter the password again for another sudo command.

The sudo -s command launches an interactive non-login shell. After successful authentication with the root password, all subsequent commands are executed with elevated privileges.

The SHELL environment variable or the user's default shell specifies which shell opens. If this variable is empty, the shell defined in the /etc/passwd is picked up.

By default, the sudo -s command runs from the directory of the previous user because the target user inherits the environment of the previous user. The command is also logged in your history.

To start a shell with permanently elevated privileges, enter the following command:

tux:~ > sudo -s
[sudo] password for root:
root:/home/tux # exit
tux:~ > 

The prompt changes from > to # .

You have started a shell with permanently elevated privileges. All subsequent commands are executed without prompting for the password again.

The sudo -i is similar to the sudo -s command-line option but launches an interactive login shell. When using the sudo -s command, the target user inherits the environment of the previous user. You can prevent it by using the sudo -i command, where the target user gets a clean environment and starts at their own $HOME directory.

To run a command with sudo -i, enter the following:

tux:~ > sudo -i
[sudo] password for root:
root:~ # exit
tux:~ > 

You have started a shell with permanently elevated privileges, and the command is logged in your history. All subsequent commands are executed without prompting for the password again.

The #includedir directive in /etc/sudoers ignores files that end with the ~ character or contain the . character. This is to avoid issues with configuration files provided by the package manager (containing .), or with an editor's temporary or backup files (ending in ~). Make sure that the names of your custom configuration files neither contain nor end in these characters. If they do, rename them.

The order in which the configuration files are read determines when a sudo configuration directive is applied. Directives in a file located under /etc/sudoers.d/ take precedence over the same directives in /etc/sudoers. If custom directives stated in /etc/sudoers.d/ do not work, check the order in which the files are read using visudo -c. Adjust the order, if necessary.

If you have accidentally broken your system's sudo configuration and locked yourself out of sudo, use su - and the root password to start a root shell. Run visudo -c to check for errors and then fix them using visudo.

The sudoers configuration files contain 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 as follows:

# Everything on a line after # is ignored1
Defaults !insults # Disable the insults flag2
Defaults env_keep += "DISPLAY HOME" # Add DISPLAY and HOME to env_keep3
tux ALL = NOPASSWD: /usr/bin/frobnicate, PASSWD: /usr/bin/journalctl4

Each rule follows the following scheme ([] marks optional parts):

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

ALL can be used as User_List, Host_List and Cmnd_List.

Administrators can avoid having to maintain a set of repetitive and individual rules by introducing aliases to group items. Their syntax is the same as the syntax of the rules. The following types of aliases are supported:

Think of aliases as named lists of users, groups, commands and hosts. To illustrate the power of aliases, take this example:

Host_Alias    WEBSERVERS = www1, www2, www31
User_Alias    ADMINS = tux, wilber, suzanne2
Cmnd_Alias    REBOOT = /sbin/halt, /sbin/reboot, /sbin/poweroff3
ADMINS WEBSERVERS = REBOOT4

In summary, aliases help administrators to keep sudoers lean and manageable (and therefore secure). If, for example, one of the users has left the company, you can delete this person's name from the User_Alias statement and any system group they belonged to just once instead of having to search for all rules including this particular user.