To perform authorization checking for z/OS UNIX files and directories, RACF® makes the following checks. RACF stops processing when the request is granted or denied.

1. The SAF callable services router exit (IRRSXT00) can grant or deny access before RACF authorization processing occurs.
2. If the system (kernel) is the caller, then access is failed if either of the following conditions occurs:
   • The request includes execute authority for a file and execute authority cannot be granted. In this condition, none of the permissions bits grant execute access, and, if an ACL is present and the FSSEC class is active, no ACL entry grants execute access.
   • Security label authorization checking fails. In this condition, the SECLABEL class is active, the object being accessed is a directory, the directory's SECLABEL is not SYSMULTI, and the CRED contains a SECLABEL.
   Otherwise, access is granted.
3. RACF checks for a profile in the FSACCESS class that covers the file system name when all of the following conditions are met:
   • The user does not have the AUDITOR attribute.
   • A file system name was specified in the CRED.
   • The FSACCESS class is active and RACLISTed.
   If a matching profile is found and the user does not have at least UPDATE authority, access is denied. Otherwise, access checking continues.
4. If the SECLABEL class is not active, then go to Step 15.
5. If the user has the TRUSTED or PRIVILEGED attribute, then access is granted automatically unless the user is executing a file. If the user is executing a file, access is denied only if none of the permissions bits grant execute access, and, if an ACL is present and the FSSEC class is active, no ACL entry grants execute access. Otherwise, access is granted.
6. If the user has the RACF AUDITOR attribute, and has read or search access for a directory is requested, access is granted.
7. If SETROPTS MLFSOBJ is active and the file does not have a security label, the request is failed.
8. If SETROPTS MLS is active (either in WARNING or FAILURES mode) and all of the following conditions occur, the request is failed.
   • The user has a security label.
   • The file has no security label.
   • The user explicitly requested write access but is not in writedown mode.
   Note: The SETROPTS MLS(WARNING) option is not supported for UNIX files and directories, and it is treated the same as MLS(FAILURES).
9. If the file has a security label but the user does not, then the request is failed.
10. If the user's security label is equivalent to the security label of the file (this condition is also satisfied if either security label is SYSMULTI), then continue at Step 16.
11. If ANY access is requested, then two security label dominance checks (RACROUTE REQUEST=DIRAUTH) are performed: one for READ and one for WRITE. If either succeeds, then continue at Step 16. Otherwise, the request is failed.
12. If the user is requesting write access along with read or search/execute access, then a READWRITE dominance check is performed. If it succeeds, then continue at Step 16. Otherwise, the request is failed.
13. If the user is requesting only read or search/execute access, then a READ dominance check is performed. If it succeeds, then continue at Step 16. Otherwise, the request is failed.
14. If the user is requesting only write access, then a WRITE dominance check is performed. If it succeeds, then continue at Step 16. Otherwise, the request is failed.
15. If the user has the RACF AUDITOR attribute, and read or search access for a directory is requested, access is granted.
16. If the user has UID(0), then access is granted automatically unless the user is executing a file. If the user is executing a file, access is denied only if none of the permissions bits grant execute access, and, if an ACL is present and the FSSEC class is active, no ACL entry grants execute access. Otherwise, access is granted.
17. If the UID matches the file owner UID, the file's "owner" permission bits are checked. If the "owner" bits allow the requested access, then access is granted. Otherwise, go to Step 27.
18. If the FSSEC class is active, and an ACL exists, and there is an ACL entry for the requesting UID, then the permission bits of that ACL entry are checked. If the ACL entry allows the requested access, then access is granted. Otherwise, go to Step 26.
19. If the GID matches the file owner GID, the file's "group" permission bits are checked. If the "group" bits allow the requested access, then access is granted.
20. If the FSSEC class is active, and an ACL exists, and there is an ACL entry for the requesting GID, then the permission bits of that ACL entry are checked. If the ACL entry allows the requested access, then access is granted. If not, then the next ACL entry is checked until there are no more entries.
21. If any of the user's supplemental GIDs match the file owner GID, the file's "group" permission bits are checked. If the "group" bits allow the requested access, then access is granted.
22. If the FSSEC class is active, and an ACL exists, and there is an ACL entry for any of the user's supplemental GIDs, then the permission bits of that ACL entry are checked. If the ACL entry allows the requested access, then access is granted. If not, then the next ACL entry is checked until there are no more entries.
23. If at least one matching ACL entry was found for the GID, or any of the supplemental GIDs, then processing continues with Step 26. If the GID, or any of the supplemental GIDs, matched the file owner GID, then processing continues with Step 27. Otherwise (neither the GID nor any of the supplemental GIDs matched either the file owner GID or an ACL entry), processing continues with the next step.
24. If the requesting user has the RESTRICTED attribute, and the UNIXPRIV class is active and RACLISTed, and the RESTRICTED.FILESYS.ACCESS resource is protected by a profile in the UNIXPRIV class, and the user does not have at least READ access, then go to Step 27.
25. The file's "other" permission bits are checked. If the "other" bits allow the requested access, then access is granted. Otherwise, go to Step 27.
26. If the UNIXPRIV class is active and RACLISTed, and if the SUPERUSER.FILESYS.ACLOVERRIDE resource is protected by a profile in the UNIXPRIV class, then the user must have the correct access level as documented for the ck_access (IRRSKA00) callable service in z/OS Security Server RACF Callable Services. If the profile exists, it determines whether file access is granted or denied.
27. If the UNIXPRIV class is active and RACLISTed, and if the SUPERUSER.FILESYS resource is protected by a profile in the UNIXPRIV class, then the user must have the correct access level as documented for the ck_access (IRRSKA00) callable service in z/OS Security Server RACF Callable Services. If the profile exists, it determines whether file access is granted or denied.
28. Access is denied.
29. The SAF callable services router exit (IRRSXT00) can grant or deny access after RACF authorization processing occurs.