When a user tries to access an object, Windows NT compares security information in the user's access token with the security information in the object's security descriptor, as shown in Figure 6.7:
Figure 6.7 Access Validation
A desired access mask for the subject is created based on what type of access the user is attempting. This desired access mask, usually created by a program that the user is running, is compared with the object's ACL. (All generic access types in the ACL are mapped to standard and specific access types.)
Each ACE in the ACL is evaluated in this way:
1. The security ID in the ACE is compared with the set of security IDs in the user's access token. If a match is not found, the ACE is skipped.
Further processing is based upon the type of the ACE. AccessDenied ACEs are ordered (and therefore processed) before AccessAllowed ACEs.
2. If access is denied, the system checks to see if the original desired access mask contained only a ReadControl and/or WRITE_DAC. If so, the system also checks to see if the requester is the owner of the object. In this case, access is granted.
3. For an AccessDenied ACE, the accesses in the ACE access mask are compared with the desired access mask. If there are any accesses in both masks, further processing is not necessary, and access is denied. Otherwise, processing continues with the next requested ACE.
4. For an AccessAllowed ACE, the accesses in the ACE are compared with those listed in the desired access mask. If all accesses in the desired access mask are matched by the ACE, no further processing is necessary, and access is granted. Otherwise, processing continues with the next ACE.
5. At the end of the ACL, if the contents of desired access mask are still not completely matched, access is implicitly denied.
Four examples of this access validation process are described next.