Doc / Family / ``Daddy, Can I Have Root?''

As the family system administrator and computer guru, I'm used to getting called at work when someone at home is having problems. But I was still unprepared for the latest call. When my wife put my 14-year-old daughter on the phone, she said. ``I need the root password.''

Now, root is the login name of the system administrator on a Unix or Linux machine. It's roughly equivalent to asking for the keys to the family car.

``What do you think you need to do with it?''

``My friend told me about this program: it makes the list command in IRC work better. You have to be root to install it.''

``So let me get this straight. You want to download some random program off the net and install it on the server. No. Installing stuff off the net can be very dangerous. Why don't you wait until I get home and we can discuss this...'' Just like a typical father, I guess.

As of the time of writing we still haven't had that talk, but we will. There are really four things at issue:

  1. Downloaded software isn't always safe
  2. Most users don't need root
  3. Using root safely
  4. Defending your server

Downloaded software isn't always safe

While viruses, worms, and trojan horse programs aren't as common on Linux as they are on Windows (Linux is both a smaller target, and far better protected), there are still a lot of malicious people on the Net. Even if you're not root, a program you install for your own use can still wipe out your own home directory (including your homework), and maybe a few other places where you have write permission.

It can do other things, possibly worse. It can mail your password file to a cracker site. It can look around in your home directory for a secret, like your credit card number, and mail that. It can send embarassing e-mail to all the people in your address book -- in your name! Information is different from cash and jewelry -- after it's been stolen, you still have it. How could you tell?

A program doesn't even have to be maliciously written in order to do considerable damage: just badly written. A simple script with a simple error might wipe out all your files, and it wouldn't matter that the author didn't mean to do it. It's bad enough when you do it to yourself...

That said, there are lots of ways to protect yourself.

Once you've installed software, there are more things you can do:

Most users don't need root

One thing Katy doesn't know is that she, like any Linux user, can install programs for her own use in her home directory. Most users make a subdirectory called ``bin'' (short for ``binary'' -- it's an old Unix tradition) in their home directory.

To use a personal bin directory, you have to ``put it in your PATH''. The program that actually runs commands, called the ``shell'', has a list of directories called the ``search path'' where it looks for programs to run. So when you type a command like ``ls'' or click on an icon to run Netscape, the shell looks for a file named ls or netscape in each of a half-dozen or so places, which you can list by typing:

<steve 504> echo $PATH

Notice that the directories in the path are separated by colons. To add the ``bin'' subdirectory of your home directory to PATH you need to use a text editor to put a line like this into the file called .bashrc (or, depending on how your system is set up, possibly .profile or .bash_profile) in your home directory:

    export PATH=$HOME/bin:$PATH

(If you're on a BSD-based system, or your system administrator was trained on one, you may be using csh or tcsh instead of bash as your shell. In that case you need to edit .cshrc instead of .bashrc, and add:

    set path = ( $HOME/bin $path )


In order for this to take effect, you will probably have to log out and log back in again. (You could execute the export command in an xterm window, but it would only affect that window and not your window manager, which got its PATH set up when you logged in.)

Now, when you install a program in your personal bin directory, it will run when you type its name. Provided, that is, that it's marked as ``executable''.

Take a close look at a long directory listing (ls -l) sometime.

 ls -l bin
total 77
drwxrwxr-x   2 steve    users        1024 Jul 10 23:20 CVS
drwxrwxr-x   2 steve    users        1024 Jul 10 23:22 Old
-rwxrwxr-x   1 steve    users          91 Sep  9  1994 addgroups
-rwxr-xr-x   1 steve    users         517 Apr 19  1988 autodoc
-rwxr-xr-x   1 steve    users          96 Apr 20  1990 banner_clock
-rwxrwxr-x   1 steve    users         400 Sep 18  1997 blacken
-rwxrwxr-x   3 steve    users          64 Jul 25  1997 bolero
-rwxr-xr-x   1 steve    users          40 Jul 19  1990 ccc
-rwxr-xr-x   1 steve    users          46 Jul 19  1990 ccx
-rwxrwxr-x   1 steve    users         288 Sep 18  1997 cpltree
-rwxrwxr-x   1 steve    users         258 Sep 18  1997 cptree

See the ``rwx's'' in the first column? Those stand for read, write, and execute permission, respectively. The first group of three is for me, the next for the users group, and the third for everyone else. In order for a file to be recognized as a command, the ``x'' flag has to be turned on.

Most software that you download in binary (executable) form comes in a tar archive, and anything that's supposed to be executable will still have its permissions set correctly after you unpack it. Similarly, software that you build (compile) and install yourself will be executable. The problem comes when you download just an executable program, for example using ftp or a web browser.

In this case, you have to mark the file as executable. Another way of describing this process is ``changing the file's mode'', and the command you need is chmod:

   chmod +x foo

Not so hard, is it? For more on what chmod can do, look at the online manual:

   man chmod

Using root safely

The root account can do anything, bypassing all ownership-based file permissions and other tests. Because it's so powerful, root is also called the superuser. With all that power at your fingertips, how do you use it wisely?

The main thing is: use it as little as possible. Above all, don't stay logged in as root (no matter how easy it is to dedicate a virtual terminal to it). Log in as yourself, su to root, do what you need to, and exit back to being yourself.

The sudo command makes this even easier: you can designate a set of users, and a set of commands (possibly different for each user) that they can do using their own password.

If you need to work on your home machine remotely over the Internet, get and install ssh (Secure SHell) from This is a package that provides a securely encrypted connection between two machines. In particular, passwords are encrypted, so somebody in between with a packet sniffer (there are such things) can't steal your password. ssh also provides a secure proxy for the X11 protocol, so you can use X applications over the same secure connection.

If you need to do anything complicated, (for example, making a backup tape, adding a newsgroup, copying a directory tree, etc.) write a script. Start by preceeding any dangerous commands, like rm, with echo so you can see what you're going to be doing to yourself. Add a little note to yourself in the documentation comments. For example, here's my command to copy a directory tree, staying in one filesystem:

#!/bin/csh -f
#  cpltree src dst
#  	$Id: cpltree,v 1.1 1997/09/19 04:27:18 steve Exp $
# 	copy a directory tree (on the same machine)

if ($#argv != 2) then
	echo usage: $0 src dst
if (! -e $2) mkdir $2
(cd $1; tar clf - .) | (cd $2; tar xvpBf -)

(You can tell it's from my old Sun days because it uses csh instead of bash. But it works and I haven't had to look at it for years and years.)

Defending your server

Anyone who can get to the keyboard and reboot a Linux box can ``get root'' on it by rebooting in ``single user mode''. You can make this more difficult by

  1. requiring a password on single user mode,
  2. configuring your BIOS to only boot from the hard disk
  3. putting a password on your BIOS configuration

Unfortunately, these steps also make it difficult (perhaps impossible) to repair your system when something goes wrong, and even then you're not completely safe. It's always possible for someone to take the hard drive out, put it on another machine as a secondary drive, edit the password file, and put it back. You could weld the case shut, but...

So you may as well accept the fact that your teenager is going to have root on their own machine at some point. Now what?

Family Solidarity

The best thing you can do, and the most important, is to make sure that everyone in the family understands that it's their server, their network, and their data. Make sure everyone understands how what they do affects the security of everyone else's data. Get them interested in keeping it safe. Make them active stakeholders. Make sure it's the family's machine.

As soon as a kid is ready for it, let them play around with being root on their own machine. Give them some responsibility. Make them part of the solution before they become part of the problem.

I'm not sure how you can tell when a kid is ready for this, but certainly when they figure out how to boot single-user you may as well bow to the inevitable and buy them a book on Linux system administration.

Hardening the Server

Whether the family is solidly behind you or not, it doesn't hurt to be careful. After all, it's just as easy for an untrained or careless root user to wipe out your system as it is for a malicious one. Maybe easier. Heck, it's easy enough even when you think you're being careful!

Apart from the things you do to make using root safer, there are things you can do to make your system harder to mess up.

$Id: root.html,v 1.6 2001/12/08 18:15:13 steve Exp $
Stephen R. Savitzky <>