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 ﬁle system and is used to manage and administer the system. To perform tasks such as installing or removing software and to manage system ﬁles 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 ﬁles and otherwise manage a removable device, but only root can manage “ﬁxed” hard drives by default.

This unlimited privilege, however, comes with responsibility. The root user has unlimited power to damage the system: remove ﬁles 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.

[user01@host ~]$ su - user02
Password:
[user02@host ~]$

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

[user01@host ~]$ su
Password:
[root@host ~]#

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.

Note: The su command is most frequently used to get a command-line interface (shell prompt) which is running as another user, typically root. However, with the -c option, it can be used like the Windows utility runas to run an arbitrary program as another user. Run info su to view more details.

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 conﬁgured to allow speciﬁc users to run any command as some other user, or only some commands as that user. For example, when sudo is conﬁgured 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:

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

If a user tries to run a command as another user, and the sudo conﬁguration 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.

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

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

[user01@host ~]$ 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.

[ec2-user@host ~]$ sudo -i
[sudo] password for ec2-user:
[root@host ~]#

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

Conﬁguring Sudo

The main conﬁguration ﬁle 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 ﬁle 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 % speciﬁes that this is a group, group wheel. The ALL=(ALL) speciﬁes that on any host that might have this ﬁle, wheel can run any command. The ﬁnal ALL speciﬁes that wheel can run those commands as any user on the system. By default, /etc/sudoers also includes the contents of any ﬁles in the /etc/sudoers.d directory as part of the conﬁguration ﬁle. This allows an administrator to add sudo access for a user simply by putting an appropriate ﬁle in that directory.

Note: Using supplementary ﬁles under the /etc/sudoers.d directory is convenient and simple. You can enable or disable sudo access simply by copying a ﬁle into the directory or removing it from the directory. In this post series, you will create and remove ﬁles in the /etc/sudoers.d directory to conﬁgure sudo access for users and groups.

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 conﬁgure 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 ofﬁcial 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 ﬁle 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 conﬁguring the system.

Note: In this post series, you will frequently see sudo su - used instead of sudo -i. Both commands work, but there are some subtle differences between them. The sudo su - command sets up the root environment exactly like a normal login because the su - command ignores the settings made by sudo and sets up the environment from scratch.

The default conﬁguration 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 ﬁnd 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 ﬁle, the authors of this course mostly use sudo su - in examples.

Beginners Guide to User and Group Administration on a Linux System
How to Switch User Account and Configure sudo in Linux
How to create, modify, and delete local user accounts in Linux
How to create, modify, and delete local group accounts in Linux
How to set a password management policy for users, and manually lock and unlock user accounts in CentOS/RHEL