Access-Checking

  • Article

The goal of an access check is to determine whether the subject is authorized to do what the subject wants to do. This determination is made by the function AccessCheckAndAuditAlarm, which considers the following information:

  • The subject's access token

  • The subject's desired access mask

  • The object's security descriptor

The subject's desired access mask is a data structure 32 bits long, each bit corresponding to a particular access right. Bits are turned on for rights that the subject wants, and they are turned off for rights that the subject does not want. For more information about access masks, see "Access Masks" earlier in this chapter.

When access-checking is complete, AccessCheckAndAuditAlarm returns a granted access mask to the object manager. The granted access mask is a 32-bit structure identical to the desired access mask, except that all bits are initially turned off. As the access-checking process finds authorization for each right requested in the desired access mask, the bit corresponding to that right is turned on in the granted access mask and turned off in the desired access mask. When all bits in the desired access mask are turned off, access-checking stops. The granted access mask is then returned to the calling process.

AccessCheckAndAuditAlarm uses the following rules to determine the subject's authorization:

  1. If the object's security descriptor has no DACL, then the granted access mask is set to match the desired access mask, and access-checking stops. The subject receives the access that it requests.

  2. If the desired access mask is empty, access-checking stops. The subject gains no access to the object.

  3. If the bit for the right to access the SACL is turned on in the desired access mask, the subject's access token is checked for the Manage auditing and security log (SeSecurityPrivilege) privilege. If the access token contains this privilege, the bit for SACL access is turned off in the desired access mask and on in the granted access mask.

  4. If the bits for Read Permissions, Change Permissions, or Modify Owner are turned on in the desired access mask, then the Owner SID in the object's security descriptor is compared to SIDs in the access token's User and Groups fields. If a match is found, the bits are turned off in the desired access mask and on in the granted access mask.

  5. The object's DACL is evaluated by examining each ACE in sequence, starting with the first ACE.

    • If an ACE's inheritance flags are marked INHERIT_ONLY, the ACE is skipped.

    • If the SID in an ACE does not match any SID in the subject's access token, the ACE is skipped.

    • If the ACE type is access-denied, the rights denied in the ACE's access mask are compared to the rights requested in the subject's desired access mask. If there are any matches, all bits are turned off in both the desired access mask and the granted access mask, and access-checking stops. The subject gains no access to the object.

    • If the ACE type is access-allowed, the rights in the ACE's access mask are compared to the rights in the subject's desired access mask. If there are any matches, corresponding bits are turned off in the desired access mask and turned on in the granted access mask.

    • If any bits in the desired access mask are still turned on, access-checking continues with the next ACE.

    • If the end of the DACL is reached before all bits are turned off in the desired access mask, then access is implicitly denied. Any bits that have been turned on in the granted access mask are turned off, and the granted access mask is returned to the calling process. The subject gains no access to the object.