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.
If you do everything as root, you will eventually fall victim to yourself. Instead, use sudo where you can, and sudo -s or su only when you need to.
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
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
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 sudo and see that it works.→ → . 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
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:
whoamimal The command ran with the rights of the “mal” user.
cat /etc/shadowcat: /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
/etc/shadow. Okay, so how
do we get access to that file? We use
sudo, which is as simple as the
sudo whoami[sudo] password for mal: enter mal’s password, not root’s! root
sudo cat /etc/shadowroot:!: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. 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:
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:
sudo -sStart a shell with root privileges
whoamiYes, I’m root root
exitLeave our root shell exit
whoamiBack 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”.
 They come from the Bourne
shell of which your shell is a derivitive.
also sometimes used, which comes from the C-shell family of