UNIX System Administration Handbook - Evi Nemeth [32]
3 Rootly Powers
Every file and process on a UNIX system is owned by a particular user account. Other users can’t access these objects without the owner’s permission, so this convention helps to protect users against each other’s misdeeds, both intentional and accidental.
System files and processes are owned by a fictitious user called “root”, also known as the superuser. As with any account, root’s property is protected against interference from other users. To make administrative changes, you’ll need to use one of the methods of accessing the root account described in this chapter.
The root account has several “magic” properties. Root can act as the owner of any file or process. Root can also perform several special operations that are off-limits to other users. The account is both very powerful and, in untrained or malicious hands, very dangerous.
This chapter introduces the basics of superuser access for administrators. Chapter 21, Security, describes how to avoid unwanted and embarrassing superuser access by others. Chapter 27, Policy and Politics covers the relevant political and administrative aspects.
3.1 Ownership of files and processes
Every UNIX file has both an owner and a “group owner.” The owner of the file enjoys one special privilege that is not shared with everyone on the system: the ability to modify the permissions of the file. In particular, the owner can set the permissions on a file so restrictively that no one else can access it.1
We take up the subject of file permissions in Chapter 5, The Filesystem.
While the owner of a file is always a single person, many people may be group owners of the file, so long as they are all part of a single UNIX group. Groups are defined in the /etc/group file.
See page 79 for more information about groups.
The owner of a file gets to specify what the group owners can do with it. This scheme allows files to be shared among members of the same project. For example, we used a UNIX group to control access to the source files for the first edition of this book.
Both ownerships of a file can be determined with ls -l filename. For example:
% ls -l /staff/scott/todo
-rw------- 1 scott staff 1258 Jun 4 18:15 /staff/scott/todo
This file is owned by the user “scott” and the group “staff.”
UNIX actually keeps track of owners and groups as numbers rather than as text names. User identification numbers (UIDs for short) are mapped to user names in the /etc/passwd file, and group identification numbers (GIDs) are mapped to group names in /etc/group.2
The text names that correspond to UIDs and GIDs are defined only for the convenience of the system’s human users. When commands such as ls want to display ownership information in a human-readable format, they must look up each name in the appropriate file or database.
Processes have not two but four identities associated with them: a real and effective UID and a real and effective GID. The “real” numbers are used for accounting, and the “effective” numbers are used for the determination of access permissions. Normally, the real and effective numbers are the same. The owner of a process can send the process signals (see page 48) and can also reduce (degrade) the process’s scheduling priority.
While it is not normally possible for a process to alter its four ownership credentials, there is a special situation in which the effective user and group IDs may be changed. When a command is executed that has its “setuid” or “setgid” permissions bit set, the effective UID or GID of the resulting process may be set to the UID or GID of the file containing the program image rather than the UID and GID of the user that ran the command. The identity of the process is thus “promoted” for that specific command only.
See page 70 for more information about permission bits.
UNIX’s setuid facility allows programs run by ordinary users to make use of the root account in a limited and tightly controlled way. For example,