RACF authorization

If the audit function code in the CRED is access, the real z/OS UNIX user identifier (UID) and z/OS UNIX group identifier (GID) of the calling process are used on the authority checks. Otherwise, the effective UID and GID for the calling process are used.
If the calling user has auditor authority and the access requested is search, or the access requested is read for a directory, access is allowed. Security label checking is bypassed in this case. This lets an auditor set the auditor audit options on any file without requiring that the auditor be given search access rights to all directories.
If the CRED user type is system, IRRSKA00 allows any access except when the requested access is execute and no execute permission bits are set for the file. No UIDs are used in this case, because no process exists. If the user is not system, the security label is checked and the security label authorization checking will be performed. If the SECLABEL class is active, and both a system CRED and a directory FSP are received, and the system CRED contains a security label, the access request will fail with a security label failure if the directory's SECLABEL is not SYSMULTI. No other security label authorization checking is done when a system CRED is passed. No security label checking is performed for a system CRED, with the exception that if the SECLABEL class is active, and both a system CRED and a directory FSP are received, and the system CRED contains a security label, the access request will fail with a security label failure if the directory's SECLABEL is not SYSMULTI.
If the user does not have the RACF® Auditor attribute, and a file system name was specified in the CRED, and the FSACCESS class is active and RACLISTed, RACF will check for a profile in the FSACCESS class that covers the file system name. If a matching profile is found and the user does not have at least UPDATE authority, access is denied. Otherwise, authorization is determined by subsequent checks.
If the SECLABEL class is active, security label checking is performed for any file or directory with a security label. The security label of the process will be evaluated by ck_access against the security label in the FSP of the object being accessed, according to the hierarchical security model used for mandatory access control. If MLFSOBJ is active, a failure will occur if the file or directory does not have a security label, unless the CRED contains a security label in the ROSeclabel field. This value is used to pass the resource security label for read-only file systems.

If the caller is not a superuser, the permission bits did not allow the requested access, and the audit function code is listed in Table 1, an authorization check is performed on the corresponding resource in the UNIXPRIV class. If the authorization check is successful, the caller is treated as a superuser.

If Table 2 does not result in a UNIXPRIV authorization check, the caller is not a superuser, the permission bits did not allow the requested access, the file is a directory, and requested access is search, a read authorization check is performed on the SUPERUSER.FILESYS resource in the UNIXPRIV class. If the authorization check is successful, the caller is treated as a superuser.

If a matching ACL entry was encountered for the user, or for at least one of its groups, and the requested access was not granted, then substitute SUPERUSER.FILESYS.ACLOVERRIDE as the resource name in Table 2. If SUPERUSER.FILESYS.ACLOVERRIDE does not exist, the check is redriven for the SUPERUSER.FILESYS resource.

Table 1. UNIXPRIV class resource names used in ck_access
Audit function code	Resource name	Access required
OPEN (for read or search), OPENDIR, READLINK, STAT, REALPATH, LSTAT, EACCESS (for read), ACCESS (for read; if real, effective and saved match)	SUPERUSER.FILESYS	READ
OPEN (for write), EACCESS (for write), ACCESS (for write; if real, effective and saved match)	SUPERUSER.FILESYS	UPDATE
LINK, MKDIR, MKNOD, RENAME, RMDIR, SYMLINK, UNLINK	SUPERUSER.FILESYS	CONTROL

If the user being checked is a superuser, IRRSKA00 allows any access except when the requested access is execute and no execute permission bits are set for the file. The user is considered a superuser if the selected UID is 0 or if the ACEE indicates trusted or privileged authority. The superuser that has UID 0 will not automatically pass the security label check, however, the trusted or privileged will.
If the user is not system and is not a superuser, the permission bits and ACL (if one exists, and if the FSSEC class is active) for the file are checked to see if the access requested is allowed. If the selected UID matches the owner UID of the file, the owner permission bits are checked. If the UIDs don't match, the user ACL entries are checked. If the selected UID matches an ACL entry, the ACL entry bits are checked. If a matching ACL entry was not found for the user, the group bits and the group ACL entries are checked. The selected GID and supplemental GID are checked against the file owner GID and the group ACL entries, until a match is found which grants the requested access, or until all the GIDs have been checked. If no match was found, the other permission bits are checked, unless the user has the RESTRICTED attribute, the UNIXPRIV class is active, the resource named RESTRICTED.FILESYS.ACCESS is protected, and the user does not have at least READ access.
If the real, effective, and saved UID are the same, and if the real, effective, and saved GID are the same, UNIXPRIV will be checked for AFC_ACCESS.
For a detailed list of authorization steps for z/OS® UNIX files and directories, see Appendix F, in the z/OS Security Server RACF Security Administrator's Guide.