The root User

Most operating systems have some sort of superuser, a user that has all power over the system. This user in Red Hat Enterprise Linux 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. In order to perform tasks such as installing or removing software and to manage system files and directories, a user must escalate privileges to the root user.
Most devices can only be controlled by root, but there are a few exceptions. For instance, removable devices, such as USB devices, are allowed to be controlled by a normal user. Thus, a non-root user is allowed to add and remove files and otherwise manage a removable device, but only root is allowed to manage "fixed" hard drives by default.
This unlimited privilege, however, comes with responsibility. root has unlimited power to damage the system: remove files and directories, remove user accounts, add backdoors, etc. If the root account is compromised, someone else would have administrative control of the system. Throughout this course, administrators will be 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 Windows. In Linux, most system administrators log into an unprivileged user account 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. However, on Linux, it is recommended that system administrators should not log in directly as root. Instead, system administrators should log in as a non-root user, and use other mechanisms (su, sudo, or PolicyKit, for example) to temporarily gain superuser privileges.
By logging in as the administrative user, 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.
In recent versions of Microsoft Windows, Administrator is disabled by default, and features such as User Account Control (UAC) are used to limit administrative privileges for users until actually needed. In Linux, the PolicyKit system is the nearest equivalent to UAC.

Switching Users with su

The su command allows a user to switch to a different user account. If no username is specified as an argument to the command, the root account is used. When run su is run by a regular user, a prompt will request the password of the account you are switching to. When run by root, there is no need to enter the account password.
su [-] <username>

[student@desktopX ~]$ su -
Password: redhat
[root@desktopX ~]# 

The command su username starts a non-login shell, while the command su - username (with the - 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. See info su for details.

Running Commands as root with sudo

One disadvantage of the su command is that the user running the command needs to know the password of the user to whom they want to switch. This means that any user that wants to use su to become root needs to know the root user's password.
Another disadvantage of su is that it starts a complete shell as the new user, granting the ability to do anything as that user. So using su to become root allows the user to do anything root can do -- not only can the user restart the web server, but they can also remove the entire /etc directory.
The sudo command addresses both of these disadvantages. It allows a user to run commands as another user, based on settings made by root in the /etc/sudoers file or by supplementary files it includes from the /etc/sudoers.d directory.
Unlike su, sudo normally requires users to enter their own password for authentication, not the password of the account they are trying to access. So users who use sudo to run commands as root do not need to know the actual password of the root account, only their own password.
In addition, sudo can be configured to allow specific users to run any command as some other user, or only specific commands as that user. This allows an administrator to hand out limited access to specific accounts, without needing to share that account's password or shell access.
For example, when sudo has been configured to allow the user student to run the command usermod as root, student could run the following command to lock a user account:

[student@serverX ~]$ sudo usermod -L username
[sudo] password for student: password

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

[student@serverX ~]$ sudo tail /var/log/secure
...
Feb 19 15:23:36 localhost sudo: student : TTY=pts/0 ; PWD=/home/student ; USER=root ; COMMAND=/sbin/usermod -L student
Feb 19 15:23:36 localhost usermod[16325]: lock user 'student' password
Feb 19 15:23:47 localhost sudo: student : TTY=pts/0 ; PWD=/home/student ; USER=root ; COMMAND=/bin/tail /var/log/secure

In Red Hat Enterprise Linux 7, all members of group wheel can use sudo to run commands as any user, including root. The user will be prompted for their own password. This is a change from Red Hat Enterprise Linux 6 and earlier. Users who were members of group wheel did not get this administrative access by default in RHEL 6 and earlier.
To enable similar behavior on earlier versions of Red Hat Enterprise Linux, use visudo to edit the configuration file and uncomment the line allowing the group wheel to run all commands. The visudo command works just like vi.

[root@desktopX ~]# cat /etc/sudoers
...Output omitted...
## Allows people in group wheel to run all commands
%wheel        ALL=(ALL)       ALL

## Same thing without a password
# %wheel  ALL=(ALL)       NOPASSWD: ALL
...Output omitted...

Warning

RHEL 6 did not grant group wheel any special privileges by default. Sites which have been using this group may be surprised when RHEL 7 automatically grants all members of wheel full sudo privileges. This could lead to unauthorized users getting superuser access to RHEL 7 systems.
Historically, membership in group wheel has been used by Unix-like systems to grant or control superuser access.
Most system administration applications with a GUI use PolicyKit to prompt users for authentication and to manage root access. In Red Hat Enterprise Linux 7, PolicyKit may also prompt members of group wheel for their own password in order to get root privileges when using graphical tools. This is similar to the way in which they can use sudo to get those privileges at the shell prompt. PolicyKit grants these privileges based on its own configuration settings, separate from sudo. Advanced students may be interested in the pkexec(1) and polkit(8) man pages for details on how this system works, but it is beyond the scope of this course.

In some cases, the root account may not have a valid password at all for security reasons. In this case, users can not log into root directly with a password, and su can not be used to get an interactive shell. But if they have a non-root account on the system that can use sudo to run the su command, they can run sudo su - from that account to get an interactive root shell.
It is also possible to set up sudo to allow a user to run commands as another user without entering their password. The preceding example from an /etc/sudoers file shows a commented out example of this.
While there are obvious security risks to granting this level of access to a user, it is frequently used with cloud instances and virtual machines to help configure the system. For example, the official AMI for Red Hat Enterprise Linux 7 in the Amazon Web Services Marketplace ships with the root password locked and the ec2-user password locked. The ec2-user account is set up to allow interactive remote access through SSH public key authentication. The ec2-user can also run any command as root without a password because the last line of the AMI's /etc/sudoers file is

ec2-user  ALL=(ALL)   NOPASSWD: ALL

For example, an administrator might get an interactive shell as root on a 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 a root shell.
Another way the administrator can get an interactive shell as root is to run sudo su -. In that case, the sudo command runs su - as root, and sudo is configured to allow ec2-user to do this without asking for a password. The su - command will give the user running it a root shell, and since the su command is being run as root by sudo, su won't prompt the user for any password first.
Likewise, users of Vagrant, a popular virtual machine tool for developers, typically configure sudo in the initial virtual machine template image (or "box") to grant the vagrant user access to run any command as root without a password for easy configuration of the developer's virtual machines.
In either case, 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.

Guided Exercise: Running Commands as root

In this exercise, you will practice running commands as root.
Outcomes

• Use the sudo command to run other commands as root.
• Use sudo to run su to get an interactive shell as root when the superuser does not have a valid password.
• Explain how su and su - can affect the shell environment through not running or running login scripts.

Before You Begin

Start your Amazon EC2 instance and use ssh to log in as the user ec2-user.
It is assumed that the AMI that you are using is pre-configured to allow the ec2-user to run any command as any user without a password using sudo.

Steps

1. Explore the characteristics of the ec2-user shell environment.
   
   1. View the current user and group information and display the current working directory.
      

      [ec2-user@ip-192-0-2-1 ~]$ id
      uid=1000(ec2-user) gid=1000(ec2-user) groups=1000(ec2-user),4(adm),10(wheel),190(systemd-journal) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
      [ec2-user@ip-192-0-2-1 ~]$ pwd
      /home/ec2-user
      

   2. View the environment variables which specify the user's home directory and the locations searched for executable files.
      

      [ec2-user@ip-192-0-2-1 ~]$ echo $HOME
      /home/ec2-user
      [ec2-user@ip-192-0-2-1 ~]$ echo $PATH
      /usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/ec2-user/.local/bin:/home/ec2-user/bin
      

2. Switch to root by using sudo to run su without the dash, and explore the characteristics of the new shell environment.
   
   1. Become the root user at the shell prompt.
      

      [ec2-user@ip-192-0-2-1 ~]$ sudo su
      [root@ip-192-0-2-1 ec2-user]# 

   2. View the current user and group information and display the current working directory. Note that the user identity changed, but not the current working directory.
      

      [root@ip-192-0-2-1 ec2-user]# id
      uid=0(root) gid=0(root) groups=0(root) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
      [root@ip-192-0-2-1 ec2-user]# pwd
      /home/ec2-user
      

   3. View the environment variables which specify the home directory and the locations searched for executable files. Look for references to the ec2-user and root accounts.
      

      [root@ip-192-0-2-1 ec2-user]# echo $HOME
      /root
      [root@ip-192-0-2-1 ec2-user]# echo $PATH
      /sbin:/bin:/usr/sbin:/usr/bin
      

      Important

      If you already have some experience with Linux and the su command, you may have expected that using su without the - option to become root would cause you to keep the current PATH of ec2-user (as seen in the previous step). That didn't happen! But as you'll see in the next step, this isn't the normal PATH for root either.
      What happened? The difference is that you didn't run su directly (because root doesn't have a valid password, and since you're not root you need to use a password to use su). Instead, you ran su as root using the sudo command so you didn't need a root password.
      It turns out that sudo initially overrides the PATH from the initial environment for security reasons. That variable can still be updated by the command that was run after that initial override, which is what su - will do in a moment.
   4. Exit the shell to return to the ec2-user user.
      

      [root@ip-192-0-2-1 ec2-user]# exit
      exit
      [ec2-user@ip-192-0-2-1 ~]# 
      

3. Switch to root by using sudo to run su -, and compare the characteristics of the new shell environment with those of the preceding example.
   
   1. Become the root user at the shell prompt. Be sure all the login scripts are also executed.
      

      [ec2-user@ip-192-0-2-1 ~]$ sudo su -
      Last login: Tue Apr 18 17:16:01 EDT 2017 on pts/0
      [root@ip-192-0-2-1 ~]# 

      Note the differences: the Last login message and the difference in the shell prompt.
   2. View the current user and group information and display the current working directory.
      

      [root@ip-192-0-2-1 ~]# id
      uid=0(root) gid=0(root) groups=0(root) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
      [root@ip-192-0-2-1 ~]# pwd
      /root
      

   3. View the environment variables which specify the home directory and the locations searched for executable files. Look for references to the ec2-user and root accounts.
      

      [root@ip-192-0-2-1 ~]# echo $HOME
      /root
      [root@ip-192-0-2-1 ~]# echo $PATH
      /usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin
      

      Important

      In this example, after sudo reset the PATH environment variable from the settings in the ec2-user shell environment, the su - command ran the shell login scripts for root and set PATH again, to yet another value. The su command without the - option (in the previous example in this exercise) didn't do that.
   4. Exit the root shell to return to the ec2-user shell.
      

      [root@ip-192-0-2-1 ~]# exit
      logout
      [ec2-user@ip-192-0-2-1 ~]$ 
      

4. Next, run several commands as ec2-user which require root access. Then, rather than using sudo su - to run them as root from an interactive root shell, use sudo to run those commands as root from the ec2-user shell as one-off commands.
   
   1. View the last 5 lines of the /var/log/messages. Your output may vary from this example.
      

      [ec2-user@ip-192-0-2-1 ~]$ tail -5 /var/log/messages
      tail: cannot open ‘/var/log/messages’ for reading: Permission denied
      [ec2-user@ip-192-0-2-1 ~]$ sudo tail -5 /var/log/messages
      Apr 18 17:10:10 ip-192-0-2-1 systemd: Started Network Manager Script Dispatcher Service.
      Apr 18 17:10:10 ip-192-0-2-1 nm-dispatcher: req:1 'dhcp4-change' [eth0]: new request (3 scripts)
      Apr 18 17:10:10 ip-192-0-2-1 nm-dispatcher: req:1 'dhcp4-change' [eth0]: start running ordered scripts...
      Apr 18 17:16:01 ip-192-0-2-1 su: (to root) ec2-user on pts/0
      Apr 18 17:18:12 ip-192-0-2-1 su: (to root) ec2-user on pts/0
      [ec2-user@ip-192-0-2-1 ~]$ 
      

   2. Make a backup of a configuration file in the /etc directory.
      

      [ec2-user@ip-192-0-2-1 ~]$ cp /etc/motd /etc/motdOLD
      cp: cannot create regular file ‘/etc/motdOLD’: Permission denied
      [ec2-user@ip-192-0-2-1 ~]$ sudo cp /etc/motd /etc/motdOLD
      [ec2-user@ip-192-0-2-1 ~]$ 
      

   3. Remove the /etc/motdOLD file that was just created.
      

      [ec2-user@ip-192-0-2-1 ~]$ rm /etc/motdOLD
      rm: remove write-protected regular empty file ‘/etc/motdOLD’? y
      rm: cannot remove ‘/etc/motdOLD’: Permission denied
      [ec2-user@ip-192-0-2-1 ~]$ sudo rm /etc/motdOLD
      [ec2-user@ip-192-0-2-1 ~]$ 
      

5. This concludes this exercise. Log out and stop your Amazon EC2 instance.