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 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
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:
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
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.
cvs. Put the version repository (CVSROOT) on another disk drive from the one your home directory is on.
metalab.unc.eduare good, but break-ins aren't unknown.
Once you've installed software, there are more things you can do:
cp valuable-file.foo valuable-file.foo.bak
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
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
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
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
.bash_profile) in your home directory:
(If you're on a BSD-based system, or your system administrator was trained
on one, you may be using
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
xterm window, but it would only affect that window and not
your window manager, which got its
PATH set up when you
Now, when you install a program in your personal
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 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 +x foo
Not so hard, is it? For more on what
chmod can do, look at
the online manual:
root account can do anything, bypassing all
ownership-based file permissions and other tests. Because it's so
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,
root, do what you need to, and
exit back to
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
ssh (Secure SHell) from OpenSSH.org. 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
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
#!/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) # STAY ON ONE FILE SYSTEM if ($#argv != 2) then echo usage: $0 src dst exit endif 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
bash. But it works and I haven't had to look at
it for years and years.)
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
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?
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.
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
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.
katyhas her own machine, called
chaos, set up
/etc/exportsto make sure that the only directory exported with read-write access to
/home/katy. Don't even allow read access to the rest of
The reason for this is simple:
root can change user
ID's to look like anyone else, and can do it without a password. Even
if someone doesn't have
root access on a machine, they can
still read and write the files of any ordinary user if they can access
them over NFS (the Network File System). Oops!