Operating Systems

Managing Your Unix Superusers

3 Pages

Herding cats, stuffing snakes in a box, managing your z/OS Unix superusers—all are examples of impossible tasks. Well, perhaps all but the last one. With some planning and communication, RACF, or an equivalent mainframe security product, really makes it possible to manage your superusers.

Before we can manage a superuser, it’s necessary to define one. In the z/OS Unix environment (also known as OMVS, MVS/OE, or Unix System Services), there are two users: a normal user and a superuser. The normal user is exactly that, someone who uses the system, but has no extraordinary privileges. On the other hand, superusers can:

  • Pass all security checks so they can access any file in the file system
  • Manage processes (or tasks)
  • Have an unlimited number of processes running concurrently. (For a started procedure, this is true only if it has a Unix id [uid] of zero. It isn’t true for a trusted or privileged process with a different uid.)
  • Change identity from one uid to another
  • Increase any of the system limits for a process.

While some functions may require a uid of zero, usually there are three ways to authorize the request. The goal is to minimize the number of “human” user IDs (as opposed to started procedures: daemons and servers) set up with superuser authority by assigning uid(0). To introduce the choices:

  • uid(0) gives you access to all Unix functions and resources, as is true for all Unix systems.
  • Certain users can perform specific privileged functions without being defined as uid(0) in the security system. The RACF BPX.SUPERUSER resource lets a user request an effective uid(0), but they’re a nomal (nonzero uid) user until the change is requested via the su command. There also are some z/OS services, such as SMP/E, that can be invoked without being uid(0) but with access to BPX. SUPERUSER.
  • UNIXPRIV class profiles authorize users to perform other sets of privileged functions, such as mounting a file system, killing a process and more, without requesting a change of uid.

The three methods are detailed here in order of their likelihood of being used—and in the inverse order of desirability.


The first and oldest method for a user to become a superuser is to be defined to Unix as uid(0). This method is implemented in z/OS by providing the user with an OMVS segment on their userid—with the uid(0) operand specified (see Figure 1). This method places the user into superuser mode as they logon to z/OS Unix. If the user’s logon script has been compromised (as in a Trojan horse attack), any restricted commands in their script are executed in superuser mode. There are ways to mitigate this exposure.


If the user is required to have access to uid(0) to perform their job functions, rather than define them with uid(0) in their OMVS segment, provide them with their own, unique uid and grant them READ access to the BPX. SUPERUSER profile in RACF.

The BPX.SUPERUSER profile, defined in the FACILITY class, grants users with READ access (greater than READ has no meaning) permission to specify the Unix switch (or substitute) user command (su) without specifying a userid and become a superuser with a uid of 0. While a superuser, enter the exit command and return to the nonzero uid.

3 Pages