ACF2 Security for Unix System Services - An Overview

This document presents an overview of how OMVS security is implemented in ACF2. Refer to the references at the end of the document for more detailed information.


There are two kinds of profiles used for OMVS security:
User Profile
Every OMVS user must have one. It contains the OMVS
Group Profile
An OMVS user must also have a GROUP name in his LOGONID record which corresponds to an OMVS Group Profile. The Group Profile contains the OMVS gid (group id). OMVS users can also be permitted to use additional OMVS Groups via ACF2 resource rules with type TGR.
User and group ids are numbers that can range from 0 to 2,147,483,647. From an OMVS perspective, if two users have the same uid, they are the same user. OMVS treats uid 0 as a "Super-User" who can access any file in the OMVS file system. Some special OMVS functions such as mounting file-systems can only be performed by a "Super-User".

From the OMVS profiles, ACF2 builds four tables which map:

  1. ACF2 user name to OMVS uid
  2. ACF2 group name to OMVS gid
  3. OMVS uid to ACF2 user name
  4. OMVS gid to ACF2 group name
Because these tables are heavily used in an OMVS environment, they are kept memory-resident and must be rebuilt to reflect changes to user and/or group profiles. If TGR resource rules are used to define additional groups, then these rules must also be memory resident.

Default OMVS User and Group

ACF2 includes support for a default user and group profile which are used when there is no OMVS user profile for an MVS user. These are specified using the GSO OPTS record - DFTOMVSU and DFTOMVSG. You specify the user or group name not the uid or gid. The default OMVS user does not have to be given a logonid. You only need to define the OMVS user and group profiles. Check with CA-ACF2 Technical Support to make sure you are at an appropriate maintenance level. Note that, at OS/390 V2R5 and higher, an OMVS user profile is required to use TCP/IP services such as FTP. See z/OS Unix System Services Default UID for some related information.

Access to Data

Security APIs

OMVS uses SAF callable services, which are processed by ACF2, to perform functions which need to interact with the security product. For example, an OMVS "daemon", performing an action on behalf of an OMVS user, could invoke an OMVS service to change its OMVS uid. Such a request would need to be permitted by the security product.

In order to use OMVS security APIs which extract ACF2 logonid information or OMVS user or group profiles, the user must have sufficient ACF2 authority to view the associated ACF2 profiles and/or logonid information. For instance, to list all OMVS users, you require at least the ACF2 AUDIT privilege for all OMVS userids plus the associated user and group profiles. This differs from the RACF implementation.

There are several resources defined through SAF which control access to special OMVS privileges. For instance, BPX.SUPERUSER is used to control the ability to switch to a "Super-User" without specifying a password.

Further Reading

The following books contain more detailed information:

Here is a general discussion of Unix Security .

Refer to the Computer Associates page here for more information about CA-ACF2.

Big Iron