Privilege, in the simplest terms, is the ability to override system restrictions on the actions of users. All operating systems allow users to exercise special privilege, under certain conditions, to perform sensitive system operations. Sensitive system operations are those which affect the configuration of the system or its availability to users.
Most users cannot, for example, execute commands affecting the hardware or software configuration of the system. Activities such as mounting and checking file systems, adding users, modifying user profiles, adding and removing peripherals, installing application software, password administration, and administration of the user terminal lines, are restricted to certain users.
In UNIX System V Release 4.0 and previous releases, the restriction of privilege is implemented by designating a special user identifier (UID) of 0; the login name historically associated with this UID is root.
When a person logs in as root, that person has unrestricted access to every file on the system, and the ability to alter system operation. Commands that execute sensitive system operations check to see whether the effective UID of the process requesting the operation is 0. If it is, the user process is given unlimited access to the system.
The root login in UNIX System V Release 4.0 and previous releases possesses, in effect, the one privilege necessary to override all system restrictions on command execution and access: the superuser privilege.
In releases after 4.0, this privilege mechanism is supplemented with a more flexible mechanism to suit the needs of the user community. Now, rather than investing the power to issue any command on the system to one user, you can give partial super-user power to several users. By assigning privileges linked to specific tasks, you essentially assign a role to each such user.
This privilege mechanism is actually a combination of the old UID functionality supported in the UNIX operating system for over 20 years, and new, discrete privilege functionality.
The most important advantage of this privilege mechanism over the pure UID-based privilege mechanism is the fine granularity with which it can apportion system privileges to executing processes. For example, you might assign someone to the role of mail administrator. That person would have all the privileges necessary to oversee maintenance and troubleshooting of the mail subsystem, but no others; he or she would not be able to add and delete user accounts, reorganize file systems, or do any other administrative work unrelated to electronic mail.
The superuser privilege can be replaced by a list of discrete privileges based on the categorization of sensitive system operations into groups of operations exercising the same kind of privilege. In other words, many different commands might need to override discretionary read access restrictions on files to perform their functions; defining a privilege such as P_DACREAD, and designating it as one of the possible privileges a command can have allows for a more controlled propagation of privileges by processes than the superuser privilege.
This means that there are two ways to acquire privilege with the superuser module (SUM) provided in SCO OpenServer: first, when the effective UID of a new process is equal to the tunable parameter PRIVID, and also, when an executable with fixed privileges is executed. With PRIVID set equal to 0, this behavior preserves the omnipotence of a process with effective uid 0. The system is delivered with PRIVID equal to 0.
It is important to recognize that the list of system privileges, and fixed privileges on files, are all part of the basic privilege mechanism provided by the operating system.