Jul 24 ’07

Managing Your Unix Superusers

by Editor in z/Journal

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:

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:

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.

The benefits of this approach include:


The UNIXPRIV class houses profiles that subdivide superuser privileges. By determining which privileges a user actually requires, it becomes possible to grant those powers to a non-zero uid.

The UNIXPRIV class in RACF is designed to grant Unix superuser privileges on a granular basis. The class must be RACLISTED and global access checking isn’t supported. Auditing of profile usage is different. Whereas most profile access failures are logged, UNIXPRIV primarily logs successful accesses by default, RACLISTED profile usage isn’t logged and failure to gain access to these profiles isn’t a violation, but a denied attempt to use optional extra services.

There are several profiles available for the granular delegation of superuser privileges.

The SUPERUSER Profiles

There’s a set of profiles that grant pieces of superuser authorization—this means that security can give out only the necessary privileges where needed.

SUPERUSER.FILESYS grants access to all local (no access to NFS files granted by this profile) directories and files at the level of access listed below.

Authorizing a user to this profile may grant access to more files than desired. If there are files or directories to be excluded from this global authorization, defining another profile, SUPERUSER.FILESYS.ACLOVERRIDE, brings additional restrictions into play by means of using the Access Control Lists (ACLs) for the files and directories.SUPERUSER.FILESYS.ACLOVERRIDE is a discrete profile specifying that ACL controls take precedence over access granted by the SUPERUSER.FILESYS profile. However, access can still be granted for specific userids—if given the same level of access to this resource as granted by the SUPERUSER.FILESYS profile.

Another authorization profile is the SUPERUSER.FILESYS,** which grants all the file system privileges to these users granted access to this profile, according to their level of access.

When given read access to the SUPERUSER.FILESYS.CHOWN profile, the user may use the Unix change owner (chown) command to change the ownership of any file (as shown in Figure 2) just like a superuser in Unix. Note that the RACF violation message (ICH408I) appears in SYSLOG and not the user’s session.

SUPERUSER.FILESYS.MOUNT profile allows the user to issue the MOUNT, UNMOUNT and CHMOUNT TSO commands:

In a similar separation of authorities, the SUPERUSER.FILESYS.QUIESCE profile allows use of the quiesce and unquiesce commands where the nosetuid (READ access required) or seteuid (UPDATE required) has been specified.

Read access to the SUPERUSER. FILESYS.PFSCTL profile allows the user to call the pfsctl() service.

When a user has read access to the SUPERUSER.FILESYS.VREGISTER resource, he is authorized to call the vreg() service, enabling him to register as a VFS file server. This only lets a server such as Network File System (NFS) initialize. Those users who are clients to such facilities don’t gain special privileges based on this or any UNIXPRIV resource profiles.

Additional privileges are granted by other UNIXPRIV class profiles. For example, IPC.RMID access should be granted to users who use the ipcrm command to release IPC resources. When it’s necessary to grant a user access to various system processes (Unix tasks), the SUPERUSER.PROCESS.** family of resource profiles come into play.

The SUPERUSER.PROCESS. GETPSENT controls what output a user or application sees from _getpsent() service calls (see Figure 3).

Or, users requiring the ability to call the kill() service for sending signals to any process should be given READ access to the SUPERUSER.PROCESS. KILL resource.

The SUPERUSER.PROCESS. PTRACE profile controls use of the ptrace() callable service through the dbx debugger for tracing any process. SUPERUSER.SETPRIORITY lets the user increase his own priority.

While there are other profiles in the UNIXPRIV class, one final profile of interest is the SHARED.IDS profile. It serves as both a switch and an access profile.

This feature is available only where the structure of the RACF database has been upgraded by the IRRIRA00 utility to make these checks practical.

The most commonly shared userid is uid(0) or superuser. When you’re ready to switch your users to their new, non-zero uids, the IBM manual Unix System Services Planning GA22-7900-10 has a section detailing the steps to be followed.


Many of the services required by users who need to support the z/OS Unix environment can be made available without the “all or nothing” approach of classic Unix. Defining the appropriate UNIXPRIV profiles and authorizing those users needing the authorization by means of access to UNIXPRIV resources makes it possible. If UNIXPRIV parceling of authorities can’t resolve the issues, strive to make BPX.SUPERUSER your solution before sharing uid(0) between Unix daemons, servers and personnel.

It’s possible to request RACF log any unauthorized attempts to gain superuser status by way of the su command. While there’s no RACF logging of successful switching from normal to superuser mode, the effective uid is recorded in most SMF records written by the actions of the uid(0) user. UNIXPRIV won’t help herd cats or stuff snakes in a box, but it can make managing your superusers possible. Z