|
Unix and its clones, among which is Linux, have been
designed as multi-user systems. This was inevitable since back in those days,
personal computers simply didn't exist. A network structure consisted of a
server, the mainframe, to which the clients connected via 'dumb' terminals.
A centralized and shared resource requires someone maintaining
it, the system administrator, also known as 'superuser', or 'root'.
The account name 'root' for this function is customary, but not obligatory.
I think it stems from the fact that 'root' is the only account having write
permissions on the '/' (or 'root') directory, which is the root of the file
system (thus the name).
'root's power does not come from its name but from its user ID, which is
'0':
# echo $UID
0
The file
permissions system in Unix is programmed to restrict access for all users
on a system, except for the user account (or accounts) which do have the UID
0 in '/etc/passwd':
root:x:0:0:root:/root:/bin/bash
Since everything in Unix is done via files, this means
absolute control over the system.
Notice that 'root' is sometimes also referred to as 'rute'
in an attempt to honor the fact that there are also female system administrators.
Don't look at me like that, it wasn't my idea ;-)
 section index  top
It is very tempting for users new to Unix-like systems,
especially those who come from operating systems without a permissions system,
to get rid of this system by logging into the 'root' account and staying there.
While this is a momentary relief, there are many good
reasons you should get used to doing your everyday work on the system on a
user account.
'root' is the administrator account
OK, this may sound lame at first, but hear me out. You
can shoot yourself in the foot royally on every operating system. Operating
system designers and implementers usually do their best to prevent you from
doing that. But these mechanisms only work if you use the system how it was
intended to be used.
The Unix operating system assumes that 'root' knows exactly what
he is doing. Remember that when Unix came into being, administrators were
masters over huge networks in a time were the average man on the street hadn't
even heard of computers.
For 'root' there is no safety net whatsoever, no 'are you really sure you
want to do this?' dialogs, no automatic backups. If you screw up as 'root'
in Unix, you really screw up.
"Here's another story. Just imagine having the
sendmail.cf file in /etc. Now, I was working on the sendmail stuff and had
come up with lots of sendmail.cf.xxx which I wanted to get rid of, so I typed
rm -f sendmail.cf. *. At first I was surprised
about how much time it took to remove some 10 files or so. Hitting the interrupt
key, when I finally saw what had happened was way to late, though."
(Richard Eiger in comp.unix.admin)
He wanted to type rm -f sendmail.cf.*. The
extra space expanded the command to "delete a file called sendmail.cf. and
every other file in the directory (*)" ...
You are much more likely to damage a Unix system using
it as 'root' as you are for example in Windows 9x. Because the designers of
Windows 9x knew that there were no permissions in this system worth speaking
of they invented other methods to protect you and your system.
Not the Unix way
What's the point in using a different operating system
when you just make it act like the one you already know? Apart from the fact
that this strategy won't work anyway, what do you do if you're on a different
Unix system and don't have the possibility to become 'root'? You will never
feel at home as long as you don't accept that some things are done differently
on Unix, and done differently for a reason, not just to annoy you (although
it can pretty much look like that sometimes *grin*).
Security
All processes started
by 'root' have 'root' privileges, which means they can do pretty much everything
they want. It doesn't even need to be a malicious program like a virus or
a worm. Those are very rare in Linux (so far).
Programming errors do happen, and even more so in Linux programs, which rely
on the user as an active tester, than in Windows, where testing is usually
donebefore a product is released. This is possible because the programmers
can rely on the permissions mechanism in Linux to prevent their programs from
doing any real damage. If you circumvent that by starting these programs as
'root', you don't have any justified reason to complain afterward when your
system is broken.
But there's another point. Even mature programs can contain security related
programming errors (also known as 'exploits'). These errors can allow an
attacker to execute commands of his own design with the permissions of the
faulty program. If this program runs with 'root' privileges, you have basically
handed over the control to this malicious intruder.
The baseline is: only be root when it is absolutely necessary
for the task at hand.
section index top
Of course there are tasks which require 'root' privileges,
but these are not everyday issues. What's more is that when you use tools
like the Mandrake Control Center, you will be prompted for the 'root' password
automatically if you are not 'root'. And there are other tools which allow
you to assume and drop 'root' privileges whenever you need to. These will
be discussed on the next page.
Generally speaking, there are only two tasks which require
'root' privileges:
-
Moving files or directories into or out of system
directories, copying files into system directories. Moving files out of system
directories requires root privileges, because the original file is deleted
in the process.
Installing software belongs here, too. RPMs usually install to system directories
which are writable by root only. If you are compiling from source, you can
configure most software to install and run from your user home directory,
in which case you don't need 'root' privileges to install the software.
Notice that compiling software does not require 'root' privileges
when done in your home directory and in fact shouldn't be done as 'root' for
security reasons.
-
Writing to files in system directories. This involves
editing system configuration files, either by hand or by a utility, but also
running programs which write output to files in system directories like 'updatedb'.
Notice that many programs allow a 'per user' configuration by files in the
user's home directory.
Another case is changing permissions on files or directories you do not own.
Notice that in case to access files in system directories, you don't
need to be root in the vast majority of cases. You can read most configuration
files and all documentation files just fine from your user account.
So, what are these fabled utilities which allow
you to become root at will, then?
section index top
 su, kdesu and sudo
|
