Inherited and direct Access Control Entries. And auto-propagation.
Any time the ACL editor updates an ACL on a folder, Windows visits every child, deleting all of the old inherited ACEs and creating new ones based on the parent’s new settings (note that this doesn’t touch any direct ACEs on the child). If this results in a child’s ACL changing, the same process continues down the tree recursively. Can this be expensive? Yes! Is it worth it? Absolutely. In large systems this helps an administrator cope with hundreds of thousands of objects. It helps avoid chaos by keeping the tree consistent, and consistency in security policy leads to better security!
Go back to the parent folder and edit the ACE again to grant yourself full control once more. Verify that this change has propagated to the child folder. Auto-propagation is a neat feature, don’t you agree? It was introduced in Windows 2000, and you should know that it’s not perfect. Here’s the first problem with it: The Win32 API exposes two families of functions for submitting new ACLs. There are the “low-level” functions such as SetFileSecurity, and then there are the “high-level” functions called SetSecurityInfo and SetNamedSecurityInfo. If you ever need to programmatically update ACLs on folders, registry keys, or any other type of container object in a hierarchy, know this: The low-level functions do NOT auto-propagate inheritable ACEs. You should avoid them! If you use the managed classes being introduced in version 2.0 of the CLR to update ACLs, you’ll be fine, because they do the right thing.
DACL and deny order of evaluation.