Revision / Modified: Feb. 11, 2002
Author: Tom Berger
Original documents:
http://www.mandrakeuser.org/docs/admin/aroot.html
http://www.mandrakeuser.org/docs/admin/aroot2.html
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 ;-)
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.
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 typedrm -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.
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*).
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 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', 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.
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?
Administrative tasks do not require you to login anew, instead you just type
su
at a (virtual) shell prompt and supply the root password. Now you are 'root' and can run any program as 'root', even graphical ones. You can return to your user account by hitting <CTRL d>.
A convenient way saving you many 'su's is to open a virtual terminal,
running su once and use it for all the 'root' tasks during your
session.
Of course you have to be sure that no one has physical access to your computer
during this session. Furthermore it is advisable to close this terminal or to
log out of the 'root' account while you are online.
One important thing to keep in mind are the different $PATH settings for users and root:
So, if there is an executable in '/usr/local/bin', 'root' will have to supply the full path to run this application, otherwise the shell will just return 'not found'. Same goes for executables in the 'sbin' directories and users.
If you want to preserve environment variables like $PATH, use
su -p
Now root's $PATH is the same as the user's who su'd. Note that this command
will show the user's home directory as root's home directory (since $HOME is
preserved)!
The disadvantage of this switch is that directories which usually contain
administrative commands like '/sbin/' and '/usr/sbin' are now no longer part
of 'root's' $PATH. You have to supply the full path now if you want to run
executables from this directory or adjust the $PATH setting.
Another convenient option for 'su' is '-c':
su -c "command"
will execute command as 'root' and then immediately return to
the user account. One drawback is that command line completion doesn't work
with su -c, so if you want to install an RPM, you better type
rpm -i rpm<TAB> first and then put su
-c in front of it. Do not forget to add the quotes around the command to
be executed.
Another drawback is that you can't start graphical programs this way.
You can shorten this somewhat arduous procedure procedure by adding this line to '/etc/inputrc':
"\C-xs": "\C-e\"\C-asu -c \""
and from the next session on you just hit <CTRL x> on any given command line to turn it into su -c "command"!
'kdesu' is KDE's way to run applications with 'root' privileges on a user's desktop. The syntax is like that of 'su':
kdesu -c "command"
This will pop up a small window asking for the root password and then execute the program as 'root'.
You can run any program as 'root' via a graphical login window, you just have to create an entry in the menu for it and use the 'kdesu -c ""' command around the command which invokes that program.
Notice that all other desktops and window managers will use 'kdesu', too, as long as the 'kdebase' package is installed. I haven't found out yet what Mandrake Linux provides in case kdebase isn't installed. Maybe some KDE hater can help me out here ;-).
'sudo' is a highly sophisticated but yet quite easy to use tool to let users do some tasks as root, even in a large network. 'sudo' supports extensive logging in connection with '/etc/syslog.conf' and the internal mailing system.
You can either get the source from 'sudo's home page or install it your Mandrake Linux CD. Control freaks and network administrators should get the source since there are a lot of important options to choose from at compile time, for everyone else (me included :)) the RPM will do.
'sudo's configuration file is '/etc/sudoers'. You configure it with the command visudo (man visudo). For those of you not familiar with the 'vi' editor, here are some basic commands:
However, you can use another editor by setting the system variable $EDITOR appropriately (e.g. export EDITOR=/usr/bin/emacs).
You'll find the main documentation in man sudoers. It is very
concise and exhaustive, in most cases however reading the EXAMPLES section
will do.
A very simple example of '/etc/sudoers' for a single-user machine would
be:
# Host alias specification
# User alias specification
# Cmnd alias specification
Cmnd_Alias RPM = /bin/rpm
Cmnd_Alias SHUTDOWN = /usr/sbin/shutdown
# User privilege specification
root ALL = (ALL) ALL
jim ALL = NOPASSWD: RPM, SHUTDOWN
The three aliases sections are used to define internal variables which can
then be used in the last section.
The first 'ALL' refers to machines in the network, which you can define
with Host_Alias. Since this is a stand-alone machine, it doesn't
matter.
This sudoers file allows user 'jim' to install and remove RPM's and tarballs,
and to shutdown the machine. The syntax is
sudo command (e.g. sudo rpm -i blah.rpm, no quotes!)
'NOPASSWD' means just that: 'jim' won't have to provide a password. You
have to specify this option explicitly because by default 'sudo' asks for the
account password before executing the command. You should use this option only
if no other Linux literate has physical access to your machine. Furthermore
you can set the option passwd_timeout min to specify
how long the password will be kept in memory. A funny option is
insults which will insult everyone who provides a wrong password
:-).
There are lots of security related options you should consider carefully if
working in an untrusted environment.
To list the sudo rights of the current user, type sudo -l:
User jim may run the following commands on this host:
(root) NOPASSWD: /bin/rpm
(root) NOPASSWD: /usr/sbin/shutdown
This will allow you to do the two most common administrative tasks on your machine more conveniently without compromising your security that much.