% Linux Installation and Getting Started    -*- TeX -*-
% hats.tex
% Copyright (c) 1993 by Matt Welsh and Lars Wirzenius
%
% This file is freely redistributable, but you must preserve this copyright 
% notice on all copies, and it must be distributed only as part of "Linux 
% Installation and Getting Started". This file's use is covered by
% the copyright for the entire document, in the file "copyright.tex".

\section{ About Root, Hats, and the Feeling of Power }\label{sec-hats}

	As you know, UNIX differentiates between different users, so that 
	what they do to each other and to the system can be regulated (one
	wouldn't want anybody to be able to read one's love letters,
	for instance).  Each user is given an {\bf account}, which
	includes a username, home directory, and so on.  In addition
	to accounts given to real people, there are special system-defined
	accounts which have special privileges.  The most
	important of these is the {\bf root account}, for the 
	username {\tt root}. 
\index{system-defined accounts!root@{\tt root}}
	
\subsection{The {\tt root} account}
\index{root account|(}
	Ordinary users are generally
	restricted so that they can't do harm to anybody else on the
	system, just to themselves. File permissions on the system 
	are arranged such that normal users aren't allowed to delete
	or modify files in directories shared by all users (such as
	{\tt /bin} and {\tt /usr/bin}. Most users also protect their
	own files with the appropriate file permissions so that other
	users can't access or modify those files.

	There are no such restrictions on {\tt root}. The user {\tt root}
	can read, modify, or delete any file on the system, change 
	permissions and ownerships on any file, and run special programs,
	such as those which partition the drive or create filesystems.
	The basic idea is that the person or persons who run and take
	care of the system logs in as {\tt root} whenever it is necessary to 
	perform tasks that cannot be executed as a normal user.
	Because {\tt root} can do anything, it is easy
	to make mistakes that have catastrophic consequences when logged
	in using this account.  
\index{root account!privleges of}
	
For example, as a normal user, if you inadvertently attempt to delete
all of the files in {\tt /etc}, the system will not permit you to do so.
However, when logged in as {\tt root}, the system won't complain at all.
It is very easy to trash your system when using {\tt root}. The best
way to prevent accidents is to:
\begin{itemize}
\item Sit on your hands before you press \key{return} on a command which
may cause damage. For example, if you're about to clean out a directory,
before hitting \key{return}, re-read the entire command and make sure
that it is correct.

\item Don't get accustomed to using {\tt root}. The more comfortable you
are in the role of the {\tt root} user, the more likely you are to 
confuse your privileges with those of a normal user. For example, you
might {\em think\/} that you're logged in as {\tt larry}, when you're
really logged in as {\tt root}. 

\index{root account!using different prompt for}
\item Use a different prompt for the {\tt root} account. You should
change {\tt root}'s {\tt .bashrc} or {\tt .login} file to set the 
shell prompt to something other than your regular user prompt. For
example, many people use the character ``{\tt \$}'' in prompts for
regular users, and reserve the character ``{\tt \#}'' for the {\tt root}
user prompt.

\item Only login as {\tt root} when absolutely necessary. And, as soon as
you're finished with your work as {\tt root}, log out. The less you use
the {\tt root} account, the less likely you'll be to do damage on your
system. 

\end{itemize}
Of course, there is a breed of UNIX hackers out there who use {\tt root}
for virtually everything. But every one of them has, at some point,
made a silly mistake as {\tt root} and trashed the system. The general
rule is, until you're familiar with the lack of restrictions on {\tt root},
and are comfortable using the system without such restrictions, login
as {\tt root} sparingly. 

Of course, everyone makes mistakes. Linus Torvalds himself once accidentally
deleted the entire kernel directory tree on his system. Hours of work 
were lost forever. Fortunately, however, because of his  knowledge of
the filesystem code, he was able to reboot the system and reconstruct the
directory tree by hand on disk. 

	Put another way, if you picture using the {\tt root}
	account as wearing a special magic hat that gives you lots of
	power, so that you can, by waving your hand, destroy entire
	cities, it is a good idea to be a bit careful about what you
	do with your hands.  Since it is easy to move your hand in a
	destructive way by accident, it is not a good idea to wear the
	magic hat when it is not needed, despite the wonderful
	feeling.
\index{root account|)}

\subsection{Abusing the system}

\index{root account!eithical issues}
Along with the feeling of power comes the tendency to do harm. This
is one of the grey areas of UNIX system administration, but everyone 
goes through it at some point in time. Most users of UNIX systems never
have the ability to wield this power---on university and business UNIX 
systems, only the highly-paid and highly-qualified system administrators ever
login as {\tt root}. In fact, at many such institutions, the {\tt root}
password is a highly guarded secret: it is treated as the Holy Grail of the
institution. A large amount of hubbub is made about logging in as {\tt root};
it is portrayed as a wise and fearsome power, given only to an exclusive
cabal.

This kind of attitude towards the {\tt root} account is, quite simply, the
kind of thing which breeds malice and contempt. Because {\tt root} is so
fluffed-up, when some users have their first opportunity to login as 
{\tt root} (either on a Linux system or elsewhere), the tendency is to
use {\tt root}'s privileges in a harmful manner. I have known so-called
``system administrators'' who read other user's mail, delete user's files
without warning, and generally behave like children when given such a
powerful ``toy''. 

Because {\tt root} has such privilege on the system, it takes a
certain amount of maturity and self-control to use the account as it 
was intended---to
run the system. There is an unspoken code of honor which exists between
the system administrator and the users on the system. How would you feel
if your system administrator was reading your e-mail or looking over your
files? There is still no strong legal precedent for electronic privacy on 
time-sharing computer systems. On UNIX systems, the {\tt root} user has
the ability to forego all security and privacy mechanisms on the system.
It is important that the system administrator develop a trusting relationship
with the users on the system. I can't stress that enough.

\subsection{Dealing with users}

\index{system administration!security issues}
\index{security}
\index{system security}
\index{users!system security and}
UNIX security is rather lax by design. Security on the system was
an afterthought---the system was originally developed in an environment where
users intruding upon other users was simply unheard of. Because of this, 
even with security measures, there is still the ability for normal users
to do harm. 

System administrators can take two stances when dealing with abusive
users: they can be either paranoid or trusting. The paranoid system 
administrator usually causes more harm than he or she prevents. One of
my favorite sayings is, ``Never attribute to malice anything which can
be attributed to stupidity.'' Put another way, most users 
don't have the ability or knowledge to do real harm on the system. 
90\% of the time, when a user is causing trouble on the system (by,
for instance, filling up the user partition with large files, or 
running multiple instances of a large program), the user is simply unaware
that what he or she is doing is a problem. I have come down on users who
were causing a great deal of trouble, but they were simply acting out
of ignorance---not malice. 

When you deal with users who are causing potential trouble, don't be
accusative. The old rule of ``innocent until proven guilty'' still holds.
It is best to simply talk to the user, and question about the trouble,
instead of causing a confrontation. The last thing you want to do is
be on the user's bad side. This will raise a lot of suspicion about you---the
system administrator---running the system correctly. If a user believes
that you distrust or dislike them, they might accuse you of deleting files
or breaching privacy on the system. This is certainly not the kind of position 
that you want to be in.

If you do find that a user has been attempting to ``crack'' the system,
or was intentionally doing harm to the system, don't return the malicious
behavior with malice of your own. Instead, simply provide a warning---but
be flexible. In many cases, you may catch a user ``in the act'' of 
doing harm to the system---give them a warning. Tell them not to let it
happen again. However, if you {\em do\/} catch them causing harm again,
be absolutely sure that it is intentional. I can't even begin to describe
the number of cases where it appeared as though a user was causing trouble,
when in fact it was either an accident or a fault of my own.

\subsection{Setting the rules}

\index{users!setting guidelines for}
The best way to run a system is not with an iron fist. That may be how
you run the military, but UNIX was not designed for such discipline. 
It makes sense to lay down a simple and flexible set of guidelines for
users---but remember, the fewer rules you have, the less chance there is
of breaking them. Even if your rules for using the system are perfectly
reasonable and clear, users will always at times break these rules without
intending to. This is especially true in the case of new UNIX users, who
are just learning the ropes of the system. It's not patently obvious,
for example, that you shouldn't download a gigabyte of files and mail them
to everyone on the system. Users need help understanding the rules, and
why they are there.

If you do specify usage guidelines for your
system, make sure that the reason behind a particular guideline is
made clear. If you don't, then users will find all sorts of creative
ways to get around the rule, and not know that they are in fact
breaking it. 

\subsection{What it all means}

\index{system administration!duties}
We can't tell you how to run your system to the last detail. Most of the
philosophy depends on how you're using the system. If you have many users,
things are much different than if you only have a few users, or if you're
the only user on the system. However, it's always a good idea---in any 
situation---to understand what being the system administrator really means.

Being the system administrator doesn't make you a UNIX wizard. There are
many system admins out there who know very little about UNIX. Likewise,
there are many ``normal'' users out there who know more about UNIX than
any system administrator could. Also, being the system administrator does
not allow you to use malice against your users. Just because
the system gives you the privilege to mess with user files does not
mean that you have any right to do so. 

Lastly, being the system administrator is really not a big deal. It
doesn't matter if your system is a little 386 or a Cray supercomputer.
Running the system is the same, regardless. Knowing the {\tt root}
password isn't going to earn you money or fame. It will allow you
to maintain the system, and keep it running. That's it.

