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:
- When the user has READ access, he is authorized to issue these commands for filesystems mounted (or to be mounted) with the nosetuid option.
- If the user has UPDATE access to the profile, he’s able to issue the MOUNT, UNMOUNT and CHMOUNT commands where the setuid option is or has been specified.
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).
- Without access to the resource, the user sees only processes owned by their uid.
- With READ access to the profile, the user may see output from the ps command for all processes, as is the Unix default.
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.
- If undefined, duplicate uids and group identifiers (gids) may be assigned.
- If present, only users with RACF System SPECIAL and users with READ access to this profile may assign an existing uid or gid to another user or group. To share a uid or gid assignment, the user issuing the command (add user/alter user or add group/alter group) must specify SHARED. This profile prevents accidental (or deliberate, if the issuing user isn’t authorized) sharing of uids.
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