Using UNIXMAP class profiles to map UIDs and GIDs

For each UID that is defined in the OMVS segment of a user profile, a general resource profile named Uuid in the UNIXMAP class is automatically created. The access list of the Uuid profile contains all user IDs that have been assigned this UID.

For each GID that is defined in the OMVS segment of a group profile, a general resource profile named Ggid in the UNIXMAP class is automatically created. The access list of the Ggid profile contains all groups that have been assigned this GID.

These mapping profiles are used to provide a cross reference to user and group profiles. They provide RACF® with a performance-sensitive method of returning information for a given UID or GID when requested by z/OS UNIX or application programs.

RACF automatically maintains these mapping profiles when UIDs and GIDs are added, changed, or deleted. The UNIXMAP class does not have to be active for this to happen. RACF does this by modifying UNIXMAP class profiles appropriately when ADDUSER, ALTUSER, DELUSER, ADDGROUP, ALTGROUP, or DELGROUP commands are issued. When RACF creates UNIXMAP profiles as a result of an ADDUSER, ALTUSER, ADDGROUP or ALTGROUP command, the user ID of the command issuer becomes the owner of the UNIXMAP profile.

For example, if the following command is issued:

ADDUSER ORTIZ OMVS(UID(13))

RACF creates a UNIXMAP profile named U13 with ORTIZ contained on the access list. If the following command is subsequently issued:

ALTUSER ORTIZ OMVS(UID(55))

RACF deletes the U13 profile and creates a U55 profile with ORTIZ contained on the access list.

In general, you should not alter these profiles. However, it is possible that they might get inadvertently deleted, or damaged by database corruption. If a profile is deleted, or if the user is not contained in its access list, RACF will not be able to retrieve information for the UID or GID that the profile represented. RACF will be unable to locate the mapping profile and will send z/OS UNIX a return code indicating that the UID or GID is not known.

If this happens, an authorized user needs to repair the damage. First, see if the user name associated with the UID or the group name associated with the GID can be determined from a message displayed by RACF. For example, suppose you received an error message associated with user ORTIZ. You should display the UID associated with the user profile for ORTIZ by entering:

LISTUSER ORTIZ OMVS NORACF

If, for example, LISTUSER displays a UID of 13, you would then enter:

RDEFINE UNIXMAP U13 UACC(NONE)
PERMIT U13 CLASS(UNIXMAP) ACCESS(NONE) ID(ORTIZ)
PERMIT U13 CLASS(UNIXMAP) ID(your-userid) DELETE

If your environment has the SETROPTS NOADDCREATOR option in effect, the second PERMIT command is not necessary because RDEFINE does not put the profile creator on the access list.

If you are unable to determine the user name or group name from a RACF message, look at the output from the database unload utility (IRRDBU00) to find the user ID or group associated with a given UID or GID. The mapping profiles should then be added, changed, or deleted as appropriate to be consistent.