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 through the Windows NT Permissions Editor (found in File Manager) either directly or by inheritance. If you use a custom application that sets and changes permissions on files and directories, the Windows NT Permissions Editor may not be able to handle the ACL that the custom application creates or modifies.

Even though the logic above still applies, there is no way of precisely determining the access to the object. The following example illustrates this point.

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 Editor had been used to apply the same permissions to the file object, the AccessDenied ACE for JnrMgrs would have been ordered first in the ACL, and BobMgr would have been denied access to the file.