Example 4: When a Custom Application Assigns Permissions

Important

The three preceding examples demonstrate discretionary access control for file and directory permissions that are applied using the Windows NT Permissions Editor, either directly or by inheritance. If your organization develops its own custom application that sets and changes permissions on files and directories, it needs to order ACEs in the same way that Windows NT Permissions Editor orders them, or the Windows NT Permissions Editor won't be able to handle the ACL.

The user BobMgr wants Read and Write access to the file object that has the discretionary ACL shown next. The access token for BobMgr indicates that he is a member of the groups Users, JnrMgrs, and Everyone.

In this example, a custom application has been used to update the ACL for a file, thus confusing the usual order in which the ACEs for this file are processed. Normally, all AccessDenied ACEs are processed first.

Windows NT evaluates this ACL as follows:

1. Windows NT reads BobMgr's desired access mask to see that he is trying to gain Read and Write access.

2. Windows NT reads the AccessAllowed ACE for BobMgr and finds a match to the Read permission requested in the desired access mask.

3. Windows NT reads the AccessAllowed ACE for Everyone and finds a match to the Write permission requested in the desired access mask.

BobMgr is granted Read and Write access to the file object, even though the third ACE explicitly denies JnrMgrs access to the file object.

If the Windows NT Permissions property sheet had been used to apply the same permissions to the file object, the AccessDenied ACE for JnrMgrs would have been evaluated first in the ACL, and BobMgr would have been denied access to the file.