In subsequent labs, you will need to regularly manage the system which will require adminstrator (the “root” user) rights. Because this affects system security, we’re briefly going to introduce you to it, and you’ll practice the skills very often throughout the rest of the paper.

On a standard Unix/Linux host, superuser privileges are generally attained through the use of the substitute user command su. This is considered better than logging in as root because it creates an audit-trail, meaning we can look at the login records and determine how root privileges were gained. For example, we might look at the login record and find that a user called “test” logged into the system at 3am in the morning from some remote system in the Russian Federation (all of which are likely very unusual) and got access to the root account using su.

On modern Unix-like hosts, you also have the option of using the sudo command. Whereas su gives you a session (sub-shell) as root, sudo gives you the ability to run a single command as root. sudo -s can be used to give you a shell also, much like su.

Actually, neither command requires that you end up as root. Indeed, su is short for substitute user, so you could change to any other user. This is perhaps useful if you need to change from root to a normal user, or from a normal user to a special account, such as a database administrator.

All Unix-like systems will have su, and many will have sudo, depending on administrator preference. It is installed by default on Mac OS X and Ubuntu, and is many other Linux systems. One of the things that make both Ubuntu and Mac OS X a bit different is that the root account is by default locked on both systems, and require the use of sudo to gain priveleges.

sudo has a different authentication model than su or practically any other authentication system you will have used. Instead of having to enter in the root password – assuming that account is not locked – you instead enter your own password. This is to authenticate yourself to the sudo command, as someone else may have started using your account if you had left your workstation unattended for a while. The system administrator (root) will have added you to a file called /etc/sudoers (which is edited using the command visudo, but don’t try that now). This allows the system administrator to grant particular users the ability to run particular commands as a particular user. This allows the system administrator the ability to give partial root access without disclosing the root password.

Because the user “mal” was the user that was created when the system was installed, that user has already been added to the sudoers file.

sudo will remember when you last successfully authenticated. If you use sudo shortly thereafter, it will not ask you for your password. By default, this timeout is 15 minutes, and can be overridden in the sudoers file.

Try the following exercise to practice getting root access. Do this in a terminal window on Client1; there should be a Terminal icon in the Gnome panel at the top of your virtual machine; if not you can use Applications → Accessories → Terminal. Before you begin, I shall explain what you will be doing. We’re first going to use our normal user account to look at the permissions on a protected file that root can only read. We’ll try to read it as a normal user, which will fail with “Permission denied”. We’ll then elevate our privileges using sudo and see that it works.

$ ls -l /etc/shadow
-rw-r----- 1 root shadow 1144 2010-06-04 09:57 /etc/shadow

We’ll see more about filesystem permissions in a later lab, but for now you’ll just need to understand that this file is not readable by a normal user, only the “root” user (and members of the “shadow” group, which we can ignore) can do anything with this file. In case you’re wondering, this file stores all the local users passwords in a secure manner, which is why it has restricted access. Let’s just verify that a normal user can’t access it:

$ whoami
mal    The command ran with the rights of the “mal” user.
$ cat /etc/shadow
cat: /etc/shadow: Permission denied

We first used the whoami command to learn the usercode we were running under; actually, what we found out is what user the whoami command was running as. The cat command outputs a file to the terminal, but it failed because the user “mal” doesn’t have access to read /etc/shadow. Okay, so how do we get access to that file? We use sudo, which is as simple as the following:

$ sudo whoami
[sudo] password for mal: enter mal’s password, not root’s!
root
$ sudo cat /etc/shadow
root:!:14621:0:99999:7:::        You see the commands output
daemon:*:14545:0:99999:7:::      which has many lines
bin:*:14545:0:99999:7:::         that are not important
…                                so we’ll use … to hide them.

Great! So we verified, using the whoami command that we can change our privileges to the “root” user, and further verified that we could now do something we couldn’t do with our regular “mal” user. Running commands as root is very common, so common that there is a common notation you will find in technical documentation^[2]. Look closely at the prompt, in the prompts you will see in this labbook, all commands that run as a normal user have a prompt of $, while all the prompts for a root-user command will have #, so in the following transcript, the first line is asking the same as the second line:

# whoami
root
$ sudo whoami
root

Sometimes, the command you need to run is too awkward to easily run using sudo, and you really want to run it from a shell. To do that, use sudo -s. Try this now:

$ whoami
mal
$ sudo -s      Start a shell with root privileges
root# whoami   Yes, I’m root
root
root# exit     Leave our root shell
exit
$ whoami       Back to where we were in line 1
mal

Exit from your root shell by tying exit or ^D. This will exit your inner, root shell, and return you to your previous shell, which was running as “mal”.