ROOT Definition

root Definition



root, which is also referred to as the root user, the administrative user, the system administrator, the root account and the superuser, is the user name or account that has access to all commands and files on a Unix-like operating system.

The word root also has several additional, related meanings when used as part of other terms, and thus it can be a source of confusion to people new to Unix-like systems.

One of these is the root directory, which is the top level directory on a system, i.e., the directory in which all other directories, including their subdirectories, and files reside. The root directory is designated merely by a forward slash ( / ).

Another is /root, a directory that should not to be confused with the root directory. /root is the root user's home directory, and it is a subdirectory of the root directory, as indicated by the forward slash that begins its name. A home directory is the primary repository of a user's files, including that user's configuration files, and it is usually the directory that a user is put into when it logs into a system. Home directories for users other than root are by default created in the /home directory, which is another standard subdirectory of the root directory.

Root privileges are the powers that the root user has on the system. The root user is the most privileged user on the system and has absolute power over it (i.e., complete access to all files and commands). Among root's powers are the ability to modify the system in any way desired and to grant and revoke any permissions (i.e., the ability to access specific files and directories) for any other users, including any of those by default reserved for root.

A rootkit is a set of tools used by an intruder, after breaking into a computer and obtaining root access, in order to maintain such access, hide traces of it and exploit it.

The use of the term root for the all-powerful administrative user may have arisen from the fact that root is the only account having write permissions (i.e., permission to write data to files) in the root directory. The root directory, in turn, takes its name from the fact that the filesystems (i.e., the entire hierarchy of directories that is used to organize files) in Unix-like operating systems have been designed with a tree-like (although inverted) structure in which all directories branch off from a single directory which is analogous to the root of a tree.

Unix-like operating systems were designed from the very beginning as multi-user systems because personal computers did not yet exist and each user was connected to the mainframe computer (i.e., a large, centralized computer) via a dumb (i.e., very simple) terminal. Thus it was necessary to have a mechanism for separating and protecting the files of the individual users while allowing them to use the system simultaneously. It was also necessary to have a mechanism that enabled a system administrative to perform such tasks as entering user directories and files to correct individual problems, granting and revoking powers for ordinary users and and accessing critical system files to repair or upgrade the system.
Every user is automatically assigned an identification number, termed a user ID or UID, by a Unix-like system, and this number is used by the system instead of the user name to identify the user. Root always has a UID of zero. This can be verified by logging in as root (if using a home computer or other system that permits this operation) and issuing the following command:

echo $UID

It can also be seen by looking at /etc/passwd, which is the configuration file for user data. This file can be viewed (by default by all users) by using the cat command, which is commonly employed to read files, i.e.,

cat /etc/passwd | less

The output of cat /etc/passwd can be piped (i.e., transferred) to the less command to allow it to be read one screenful at a time, which is useful if the file is a long one. The line of output for root will look something like root:x:0:0:root:/root:/bin/bash. The first column shows the user name and the third column shows the UID, which can clearly be seen to be zero.

The permissions system in Unix-like operating systems is a key component in the inherently outstanding security of such systems. It is set by default to restrict access to critical parts of the system and to directories and files belonging to other users for all users except for the account that has a UID of zero in /etc/passwd. This means absolute control over the system for the root user.

Thus, it can be very tempting for users new to Unix-like operating systems, especially those who are accustomed to systems with a weak permissions system or without any permissions system (e.g., Microsoft Windows or the older versions of the Macintosh), to bypass this system by logging directly into the root account and staying there. Although this provides momentary relief, it should be avoided and ordinary work on the system should be done via a user account.

This is because it is very easy to damage a Unix-like system when using it as root -- much easier than to damage most other types of operating systems. The designers of most other systems devised methods of protecting the system and data to compensate for the lack of a robust permissions system.

An important principle of Unix-like operating systems is to provide maximum flexibility to configure the system, and thus the root user is fully empowered. Unix-like systems assume that the root user knows exactly what it is doing and that only such individuals will be using the root account. Thus, there is virtually no safety net for the root user in the event of a careless error, such as damaging or deleting a critical system file (which could make the entire system unusable).

Adding to the danger of using the system as root is the fact that all processes (i.e., instances of programs in execution) started by the root user have root privileges. Programming errors are common, and even well-tested programs can contain security-related errors that can eventually allow an attacker to obtain control of a system when programs are run with root privileges rather than by an ordinary user with limited privileges.

Although operating systems are designed with mechanisms to prevent users from damaging data or the system, these mechanisms function only if the system is used as intended. A critical mechanism to keep users from damaging Unix-like systems is the requirement that the root account not be used except when absolutely necessary, even by system administrators. Even they should not log into the system routinely as root.

Rather, they should log into the system with their ordinary user (i.e., those without root privileges) accounts and then use other commands, such as su, kdesu and sudo, that allow providing root privileges only as needed and without requiring a new login.

For example, to become root with su merely requires typing

su

at the command line (i.e., in the all-text mode), pressing the ENTER key and supplying the root password. The account of the previous user can be returned to by hitting CTRL and d simultaneously or by typing the word exit and then pressing the ENTER key.

A convenient option, and one that can add to security, is -c, which tells su to execute the command as root that is typed directly following it on the same line and then immediately return to the account of the former user after the command has completed execution or after any program that it has launched has been closed.

Tasks that require root privileges include moving files or directories into or out of system directories (i.e., directories that are critical to the functioning of the operating system), and copying files into system directories, granting or revoking user privileges, some system repairs and the installation of some application programs. It is not necessary to be root to be able to read most configuration files and documentation files in system directories, although it is necessary to be root to modify them.

Root privileges are usually required for installing software in RPM (Red Hat Package Manager) package format because of the need to write to system directories. If software is being compiled from source code, however, it can usually be configured to install and run from a user's home directory, in which case root privileges are not needed to install it. Source code is the version of software as it is originally written (i.e., typed into a computer) by a human in plain text (i.e., human readable alphanumeric characters). It is converted by a compiler into machine code, which is directly understandable by a computer's processor, so that the program can be run. Compiling software does not require root privileges when done in a user's home directory, and, in fact, it should not be done as root for security reasons.

On large systems used by businesses and other organizations, there will likely be several system administrators. Each will have its own account in which it will ordinarily work (and the activities of which will be automatically recorded in system logs for security and repair purposes) but will also have access to the root account for use when necessary. The system administrator(s) might grant limited root privileges to some individuals, such as assistant administrators.