Superusers in z/OS UNIX

Your installation defines certain system programmers, users, and started procedures as superusers. Superusers pass all security checks and can access any file in the file system. They can do administrative activities such as the following:

Change the contents of any file.
Install products.
Manage processes.
Change identity from one UID to another.
Use setrlimit() or prlimit to increase any of the system limits for a process.

Superusers can also have an unlimited number of processes that are running concurrently. For a started procedure, this is true only if it has a UID of 0. It is not true for a trusted or privileged process with a different UID.

When not doing activities that require superuser authority, the superuser joins the majority of users or programs with user authority, which permits access to their own files and certain files to which they have access, according to permission bits.

Rule: The user ID associated with a started procedure needing superuser authority must have a UID, but the UID can have any value. Users running with the trusted or privileged attribute are considered superusers even if their assigned UID is a value other than 0.

The parent process propagates its UID and TRUSTED or PRIVILEGED attribute to a forked child process. Thus, a UID of 0 is propagated to a forked child.

As you are defining users, you might want to define some of them with appropriate superuser privileges. There are three ways to assign superuser authority.

With the UNIXPRIV class profiles, the preferred way. See Using UNIXPRIV class profiles.
With the BPX.SUPERUSER resource in the FACILITY class. See Using the BPX.SUPERUSER resource in the FACILITY class.
Assigning a UID of 0, which is the least desirable way. See Assigning a UID of 0.
For specific installation requirements regarding superuser authority, see Security requirements for ServerPac and CBPDO installation.

While some functions require a UID of 0, in most cases you can choose among the three ways. When choosing among them, try to minimize the number of "human" user IDs (as opposed to started procedures) set up with UID(0) superuser authority. However, in z/OS, RACF® allows certain users to perform specific privileged functions without being defined as UID(0). BPX.SUPERUSER allows you to request that you be given such access, but you do not have the access unless you make the request. And, the UNIXPRIV class allows you to do other privileged functions, such as mounting a file system. Both these definitions are similar to having UID(0) in that, before RACF grants access to a system resource or use of it, the system checks these definitions.

Do not confuse superuser authority with MVS supervisor state. Being a superuser is not related to supervisor state, PSW key 0, and using APF-authorized instructions, macros, and callable services.