Red Hat System Administration I
Switch to the superuser account to manage a Linux system, and grant other users superuser access through the
sudocommand.
Most operating systems have a superuser that has all power over the system. In Red Hat Enterprise Linux, it is the root user. This user has the power to override normal privileges on the file system, and you can use it to manage and administer the system. For tasks such as installing or removing software, and to manage system files and directories, users must escalate their privileges to the root user.
Usually, only the root user can control most devices, but some exceptions apply. 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 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 account is compromised, then the system is in danger and you might lose administrative control. Red Hat encourages system administrators to log in always as a normal user, and to escalate privileges to root only when needed.
The root account on Linux is similar 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
Microsoft Windows users might be familiar with the practice of logging in as the local Administrator user to perform system administrator duties. Today, this practice is not recommended; users obtain privileges to perform administration by memberships in the Administrators group. Similarly in RHEL, Red Hat recommends that system administrators never log in directly as root. Instead, system administrators log in as a normal user and use mechanisms (su, sudo, or PolicyKit, for example) to temporarily gain superuser privileges.
When logged in as root, the entire desktop environment unnecessarily runs with administrative privileges. A security vulnerability that might normally compromise only a normal user account can potentially compromise the entire system.
With the su command, users can switch to a different user account. If you run the su command from a regular user account with another user account as a parameter, then you must provide the password of the account to switch to. When the root user runs the su command, you do not need to enter the user's password.
This example uses the su command from the user01 account to switch to the user02 account:
[user01@host ~]$su - user02Password:[user02@host ~]$user02_password
If you omit the username, then the su or su - command attempts to switch to root by default.
[user01@host ~]$su -Password:[root@host ~]#root_password
The su command starts a non-login shell, whereas the su - command (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 is a new login as that user, whereas su starts a shell as that user, but uses the original user's environment settings.
Usually, 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 most frequent use for the su command is to get a command-line interface (shell prompt) that runs as another user, typically the root user. However, you can use the su command -c option to run an arbitrary program as another user. This behavior is similar to the Windows runas utility. Run info su to view more details.
For security reasons, in some cases system administrators configure the root user not to have a valid password. Thus, users cannot log in to the system as root directly with a password. Moreover, you cannot use su to get an interactive shell. In this case, you can use the sudo command to get root access.
Unlike the su command, sudo normally requires users to enter their own password for authentication, not the password of the user account that they are trying to access. That is, users who use the sudo command to run commands as root do not need to know the root password. Instead, they use their own passwords to authenticate access.
The next table summarizes the differences between the su, su -, and sudo commands:
su
|
su -
|
sudo
| |
|---|---|---|---|
| Become new user | Yes | Yes | Per escalated command |
| Environment | Current user's | New user's | Current user's |
| Password required | New user's | New user's | Current user's |
| Privileges | Same as new user | Same as new user | Defined by configuration |
| Activity logged |
su command only |
su command only | Per escalated command |
Additionally, you can configure the sudo command to allow specific users to run any command as some other user, or only some commands as that user. For example, if you configure the sudo command to allow the user01 user to run the usermod command as root, then you can run the following command to lock or unlock a user account:
[user01@host ~]$sudo usermod -L user02[sudo] password for user01:[user01@host ~]$user01_passwordsu - user02Password:su: Authentication failure [user01@host ~]$user02_password
If a user tries to run a command as another user, and the sudo configuration does not permit it, then bash blocks the command, logs the attempt, and sends by default an email 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 ~]$user02_password
Another benefit of sudo is to log by default all the executed commands to /var/log/secure.
[user01@host ~]$ sudo tail /var/log/secure
...output omitted...
Mar 9 20:45:46 host sudo[2577]: user01 : TTY=pts/0 ; PWD=/home/user01 ; USER=root ; COMMAND=/sbin/usermod -L user02
...output omitted...In Red Hat Enterprise Linux 7 and later versions, all members of the wheel group can use sudo to run commands as any user, including root, by using their own password.
Warning
Historically, UNIX systems use membership of the wheel group to grant or control superuser access. RHEL 6 and earlier versions do not grant the wheel group any special privileges by default. System administrators who previously used this group for a non-standard purpose must update a previous configuration, to prevent unexpected and unauthorized users from obtaining administrative access on RHEL 7 and later systems.
To access the root account with sudo, use the sudo -i command. This command switches to the root account and runs that user's default shell (usually bash) and associated interactive login scripts. To run the shell without the interactive scripts, use the sudo -s command.
For example, an administrator can get an interactive shell as root on an AWS Elastic Cloud Computing (EC2) instance by using SSH public-key authentication to log in as the ec2-user normal user. Then run the sudo -i command to access the root user's shell.
[ec2-user@host ~]$sudo -i[sudo] password for ec2-user:[root@host ~]#ec2-user_password
The /etc/sudoers file is the main configuration file for the sudo command. To avoid problems if multiple administrators try to edit the file at the same time, you can edit it only with the special visudo command. The visudo editor also validates the file, to ensure no syntax errors.
For example, the following line from the /etc/sudoers file enables sudo access for wheel group members:
%wheel ALL=(ALL:ALL) ALL
The
%wheelstring is the user or group that the rule applies to. The%symbol before thewheelword specifies a group.The
ALL=(ALL:ALL)command specifies that on any host with this file (the firstALL), users in thewheelgroup can run commands as any other user (the secondALL) and as any other group (the thirdALL) on the system.The final
ALLcommand specifies that users in thewheelgroup can run any command.
By default, the /etc/sudoers file also includes the contents of any files in the /etc/sudoers.d directory as part of the configuration file. With this hierarchy, you can add sudo access for a user by putting an appropriate file in that directory.
Note
You can enable or disable sudo access by copying a file into the directory or removing it from the directory.
In this course, you create and remove files in the /etc/sudoers.d directory to configure sudo access for users and groups.
To enable full sudo access for the user01 user, you can create the /etc/sudoers.d/user01 file with the following content:
user01 ALL=(ALL) ALL
To enable full sudo access for the group01 group, you can create the /etc/sudoers.d/group01 file with the following content:
%group01 ALL=(ALL) ALL
To enable users in the games group to run the id command as the operator user, you can create the /etc/sudoers.d/games file with the following content:
%games ALL=(operator) /bin/id
You can also set up sudo to allow a user to run commands as another user without entering their password, by using the NOPASSWD: ALL command:
ansible ALL=(ALL) NOPASSWD: ALLAlthough obvious security risks apply to granting this level of access to a user or group, system administrators often use this approach with cloud instances, virtual machines, and provisioning systems for configuring servers. You must protect the account with this access and require SSH public-key authentication for a user on a remote system to access it at all.
For example, the official Amazon Machine Image (AMI) for Red Hat Enterprise Linux in the Amazon Web Services Marketplace ships with the root and the ec2-user passwords locked. The ec2-user account is set up to allow remote interactive access through SSH public-key authentication. The ec2-user 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
You can re-enable the requirement to enter a password for sudo, or introduce other changes to tighten security as part of the system configuration.
References
su(1), sudo(8), visudo(8), and sudoers(5) man pages
info libc persona (GNU C Library Reference Manual)
Section 30.2: The Persona of a Process
(The glibc-doc package must be installed for this info node to be available.)
