Being 'root' I

Summary:

• Introducing 'root'
• Using 'root' Considered Harmful
• Tasks Which Require 'root' Privileges

Introducing 'root'

Unix and its clones and derivatives, including Linux, have been designed as multi-user systems. This is inevitable since in the days when Unix was designed, 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. Possibly it stems from the fact that 'root' is the only account which has 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 system files, except for the user account (or accounts) which have the UID 0 in '/etc/passwd':

root:x:<strong>0</strong>:0:root:/root:/bin/bash

Since everything in Unix is done via real or virtual files, this means absolute control over the system.

section index

Using root Considered Harmful

It is very tempting for users new to Unix-like systems, especially those who come from operating systems without a permissions system, to bypass this system restriction by logging into the 'root' account and staying there.

While this may seem convenient at first, 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 easily 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. *

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' than you are for example 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-like 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-like systems, and done differently for a reason, not just to annoy you (although it can pretty much look like that sometimes!)

Security

Every person who has physical access to a Unix-like computer is able to gain root access, if he gets access to the file system (e.g. floppy disk, CD-ROM drive, USB device, internet), because he can edit the '/etc/shadow' file. In this file the password for all users is stored. It can easily be edited and set to a zero password ('*'). So for perfect security you will need to secure physical access to your computer.
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, a trojan horse or a worm to cause damage. Those are very rare in Linux (so far).
Programming errors do happen, and even more so in Linux programs, which often rely on the user as an active tester, than in Windows, where testing is usually done before 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', some will say you don't have any justification to complain afterwards when your system is broken.
Furthermore, 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 control of your machine to this malicious intruder.

The summary is: only be root when it is absolutely necessary for the task at hand.

section index

Tasks Which Require root Privileges

Of course, there are tasks which require 'root' privileges, but these are not everyday issues. What's more, 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 in the next item.

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.
  Note 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, controlled by files in the user's home directory.
  Another case where you might need to be logged in as root is when changing permissions on files or directories you do not own.
  Note that in the case where you access files in system directories, you don't need to be root in the vast majority of cases. You can change to system directories and read most configuration files and all documentation files just fine from your user account.

section index

Next Item: su, kdesu and sudo

Related Resources: Revision / Modified: Feb. 11, 2002
Author: Tom Berger

Legal: This page is covered by the GNU Free Documentation License . Standard disclaimers of warranty apply. Copyright LSTB and Mandrakesoft.