How to Switch User Account and Configure sudo in Linux

The SuperUser

Most operating systems have some sort of superuser, a user that has all power over the system. In Linux, this is the root user. This user has the power to override normal privileges on the file system and is used to manage and administer the system. To perform tasks such as installing or removing software and to manage system files and directories, users must escalate their privileges to the root user.

The root user only among normal users can control most devices, but there are a few exceptions. For example, normal users can control removable devices, such as USB devices. Thus, normal users can add and remove files and otherwise manage a removable device, but only root can manage “fixed” hard drives by default.

This unlimited privilege, however, comes with responsibility. The root user has unlimited power to damage the system: remove files and directories, remove user accounts, add back doors, and so on. If the root user’s account is compromised, someone else would have administrative control of the system. Throughout this course, administrators are encouraged to log in as a normal user and escalate privileges to root only when needed.

The root account on Linux is roughly equivalent to the local Administrator account on Microsoft Windows. In Linux, most system administrators log in to the system as an unprivileged user and use various tools to temporarily gain root privileges.

WARNING: One common practice on Microsoft Windows in the past was for the local Administrator user to log in directly to perform system administrator duties. Although this is possible on Linux, it is recommended that system administrators do not log in directly as root. Instead, system administrators should log in as a normal user and use other mechanisms (su, sudo, or PolicyKit, for example) to temporarily gain superuser privileges. By logging in as the superuser, the entire desktop environment unnecessarily runs with administrative privileges. In that situation, any security vulnerability which would normally only compromise the user account has the potential to compromise the entire system.

Switching Users

The su command allows users to switch to a different user account. If you run su from a regular user account, you will be prompted for the password of the account to which you want to switch. When root runs su, you do not need to enter the user’s password.

[[email protected] ~]$ su - user02
Password:
[[email protected] ~]$

If you omit the user name, the su or su - command attempts to switch to root by default.

[[email protected] ~]$ su
Password:
[[email protected] ~]#

The command su starts a non-login shell, while the command su - (with the dash option) starts a login shell. The main distinction between the two commands is that su - sets up the shell environment as if it were a new login as that user, while su just starts a shell as that user, but uses the original user’s environment settings. In most cases, administrators should run su - to get a shell with the target user’s normal environment settings. For more information, see the bash(1) man page.

Running Commnds with sudo

In some cases, the root user’s account may not have a valid password at all for security reasons. In this case, users cannot log in to the system as root directly with a password, and su cannot be used to get an interactive shell. One tool that can be used to get root access in this case is sudo. Unlike su, sudo normally requires users to enter their own password for authentication, not the password of the user account they are trying to access. That is, users who use sudo to run commands as root do not need to know the root password. Instead, they use their own passwords to authenticate access.

Additionally, sudo can be configured to allow specific users to run any command as some other user, or only some commands as that user. For example, when sudo is configured to allow the user01 user to run the command usermod as root, user01 could run the following command to lock or unlock a user account:

[[email protected] ~]$ sudo usermod -L user02
[sudo] password for user01:
[[email protected] ~]$ su - user02
Password:
su: Authentication failure
[[email protected] ~]$

If a user tries to run a command as another user, and the sudo configuration does not permit it, the command will be blocked, the attempt will be logged, and by default an email will be sent to the root user.

[[email protected] ~]$ sudo tail /var/log/secure
[sudo] password for user02:
user02 is not in the sudoers file.  This incident will be reported.
[[email protected] ~]$

One additional benefit to using sudo is that all commands executed are logged by default to /var/log/secure.

[user0[email protected] ~]$ sudo tail /var/log/secure
...output omitted...
Feb  6 20:45:46 host sudo[2577]:  user01 : TTY=pts/0 ; PWD=/home/user01 ;
   USER=root ; COMMAND=/sbin/usermod -L user02
...output omitted...

In CentOS/RHEL 7 and 8, all members of the wheel group can use sudo to run commands as any user, including root. The user is prompted for their own password. This is a change from CentOS/RHEL 6 and earlier, where users who were members of the wheel group did not get this administrative access by default.

WARNING: CentOS/RHEL 6 did not grant the wheel group any special privileges by default. Sites that have been using this group for a non-standard purpose might be surprised when CentOS/RHEL 7 and 8 automatically grants all members of wheel full sudo privileges. This could lead to unauthorized users getting administrative access to CentOS/RHEL 7 and 8 systems. Historically, UNIX-like systems use membership in the wheel group to grant or control superuser access.

Getting an Interactive Root Shell with Sudo

If there is a nonadministrative user account on the system that can use sudo to run the su command, you can run sudo su - from that account to get an interactive root user shell. This works because sudo will run su - as root, and root does not need to enter a password to use su. Another way to access the root account with sudo is to use the sudo -i command. This will switch to the root account and run that user’s default shell (usually bash) and associated shell login scripts. If you just want to run the shell, you can use the sudo -s command.

For example, an administrator might get an interactive shell as root on an AWS EC2 instance by using SSH public-key authentication to log in as the normal user ec2-user, and then by running sudo -i to get the root user’s shell.

[[email protected] ~]$ sudo -i
[sudo] password for ec2-user:
[[email protected] ~]#

The sudo su - command and sudo -i do not behave exactly the same. This will be discussed briefly at the end of the section.

Configuring Sudo

The main configuration file for sudo is /etc/sudoers. To avoid problems if multiple administrators try to edit it at the same time, it should only be edited with the special visudo command. For example, the following line from the /etc/sudoers file enables sudo access for members of group wheel.

%wheel        ALL=(ALL)       ALL

In this line, %wheel is the user or group to whom the rule applies. A % specifies that this is a group, group wheel. The ALL=(ALL) specifies that on any host that might have this file, wheel can run any command. The final ALL specifies that wheel can run those commands as any user on the system. By default, /etc/sudoers also includes the contents of any files in the /etc/sudoers.d directory as part of the configuration file. This allows an administrator to add sudo access for a user simply by putting an appropriate file in that directory.

To enable full sudo access for the user user01, you could create /etc/sudoers.d/user01 with the following content:

user01  ALL=(ALL)  ALL

To enable full sudo access for the group group01, you could create /etc/sudoers.d/group01 with the following content:

%group01  ALL=(ALL)  ALL

It is also possible to set up sudo to allow a user to run commands as another user without entering their password:

ansible  ALL=(ALL)  NOPASSWD:ALL

While there are obvious security risks to granting this level of access to a user or group, it is frequently used with cloud instances, virtual machines, and provisioning systems to help configure servers. The account with this access must be carefully protected and might require SSH publickey authentication in order for a user on a remote system to access it at all.

For example, the official AMI for Red Hat Enterprise Linux in the Amazon Web Services Marketplace ships with the root and the ec2-user users’ passwords locked. The ec2-user user account is set up to allow remote interactive access through SSH public-key authentication. The user ec2 user can also run any command as root without a password because the last line of the AMI’s / etc/sudoers file is set up as follows:

ec2-user  ALL=(ALL)  NOPASSWD: ALL

The requirement to enter a password for sudo can be re-enabled or other changes may be made to tighten security as part of the process of configuring the system.

The default configuration of the sudo -i command actually sets up some details of the root user’s environment differently than a normal login. For example, it sets the PATH environment variable slightly differently. This affects where the shell will look to find commands. You can make sudo -i behave more like su - by editing /etc/sudoers with visudo. Find the line

Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/bin

and replace it with the following two lines:

Defaults      secure_path = /usr/local/bin:/usr/bin
Defaults>root secure_path = /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin

For most purposes, this is not a major difference. However, for consistency of PATH settings on systems with the default /etc/sudoers file, the authors of this course mostly use sudo su - in examples.