The Checking Sequence for ACL Entries
An ACL manager reads through a list of ACL entries to find the particular entry that applies to an individual who is trying to perform a particular operation. The ACL manager first looks for a match between the privilege attributes of the principal or process desiring access and the privilege attributes listed in the ACL. When the ACL manager finds a match, it examines the permissions in the matching ACL entry and applies the mask_obj mask to it (unless it is an entry of type user_obj or other_obj) if a mask_obj mask exists. Finally, the ACL manager applies the unauthenticated mask (if it exists) if the principal is not authenticated. If the permissions that result grant the requested access, the manager grants it to the principal. If not, access is denied.
Because an ACL manager stops checking the ACL entries when it finds a match, it is important to understand the order in which the ACLs are checked. The following figure shows the order of checking and the masks applied. ACL managers check entries in the following order, with the exception that the initiator principal is not checked against ..._delegate entries. Delegate principals are checked against all entries.
1. First, the ACL manager checks the user ACL entries, in the following order:
a. user_obj
b. user_obj_delegate
c. user
d. user_delegate
e. foreign_user
f. foreign_user_delegate
The ACL manager stops all entry checking at the first matching user entry it finds and applies the permissions in the entry. The user entries are checked in order as shown in the previous list from most specific to least specific.
2. If the ACL manager does not find a match in the user entries, it checks all of the following group entries:
a. group_obj
b. group_obj_delegate
c. group
d. group_delegate
e. foreign_group
f. foreign_group_delegate
If any group ACL entries match the principal's project list, and the logical OR of permissions from these entries grants access, then access is granted and no further checking is performed.
Because principals accrue permissions from all groups listed in the ACL of which they are a member (and for which they are in the project list), all the groups are checked and all the principal's group permissions are logically ORed. The order of group entry checking is not important. See Group Permissions and Project Lists for more information on project lists.
3. If the ACL manager does not find a match between the principal requesting permission and a member of a group in the group entries, it checks the other_obj and other_obj_delegate entries. If the ACL manager finds a match, it stops checking ACL entries.
4. If the ACL manager does not find a match between the principal requesting permission and the other_obj or other_obj_delegate entries, it checks the foreign_other and foreign_other_delegate entries. If the ACL manager finds a match, it stops checking ACL entries.
5. If the ACL manager does not find a match between the principal requesting permission and the foreign_other or foreign_other_delegate entries, it checks the any_other and any_other_delegate entries. If it does not find a match in the any_other or any_other_delegate entries, it denies all access to the object.
The final permission is the intersection of the permission of the initiator principal and of each delegate.
The following figure shows these steps as they apply to the ACL entries. The two columns distinguish between ACL entries that are not masked by mask_obj and those that are masked by it.
Order of Checking ACLs and Applying Masks
More:
The mask_obj Mask and ACL Checking
The Unauthenticated Mask and ACL Checking
The Effect of the Checking Order on Granting Permissions