How the System Determines if a User Can Access a Protected Object

When a user tries to access a protected object, the operating system calls the Check Protection ($CHKPRO) system service to compare the security profile of the user process with the security profile of the object. In the protection check, $CHKPRO compares the user's security profile against the protected object's profile using the following sequence:

Evaluate the access control list (ACL).
If the object has an ACL, the system scans it, looking for an entry that matches any of the user's rights identifiers. If a matching access control entry (ACE) is found, the system either grants or denies access, and further checking of the ACL stops.
When the matching ACE denies access, a user can still gain access either through the system and owner fields of the protection code or through privilege. When an ACL has no matching ACE, the system checks all fields of the protection code.
Evaluate the protection code.
If the ACL did not grant access and the object's owner UIC is not zero,^[1] the operating system evaluates the protection code. The operating system grants or denies access based on the relationship between the user's identification code (UIC) and the object's protection code.
For cases where an ACL has denied access, the system examines two fields in the protection code---the system and owner fields---to determine if the user is allowed access. The user can still acquire access by being a member of the system or owner categories or by possessing privileges. A user holding GRPPRV (with a matching group UIC) or SYSPRV is granted the access specified for the system category of the protection code.
Look for special privileges.
If access was not granted by the ACL or the protection code, privileges are evaluated.
Users with certain system privileges may be entitled to access regardless of the protection offered by the ACLs or the protection code. The bypass privilege (BYPASS), group privilege (GRPPRV), read all privilege (READALL), or system privilege (SYSPRV) amplifies the holder's access to objects. (See “How Privileges Affect Protection Mechanisms” for more information on how privileges affect access.)
Consider access overrides.
For some object classes, access may be granted based on alternate privileges. For example, the queue object allows full access to all queues for users with operator privilege (OPER), and the logical name table object allows access to the system table for users with system name privilege (SYSNAM).

“Flowchart of Access Request Evaluation” charts the sequence the operating system follows when it evaluates an access request and shows how the controlling components (ACLs, protection codes, privileges, and access overrides) interact.

Figure 4-3 Flowchart of Access Request Evaluation

Figure 4-4 Flowchart of Access Request Evaluation (cont'd)

Figure 4-5 Flowchart of Access Request Evaluation (cont'd)

Figure 4-6 Flowchart of Access Request Evaluation (cont'd)

Figure 4-7 Flowchart of Access Request Evaluation (cont'd)

^[1]When an object has an owner UIC of zero, the protection code is not checked. Users have all but control access to the object, provided the ACL has no Identifier ACEs. If Identifier ACEs are present, then access has to be granted explicitly through the ACL or through privilege.