Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm digging into the powerful but rather complex world of Windows file/folder security. I pretty much understand how it all works and can make some educated guesses how the ACL/ACE mechanism works. What I'm not sure about is how the inheritence flag/mechanism is implemented.

If (say) a folder object has the inheritence flag set, do changes to the parent:

  1. Get copied down to all effected child objects at the time the change to the parent permission is made?
  2. Does Windows, when required (e.g. checking permission) walk back up the tree to determine the inherited permission?

I'm suspecting it's #1 as if you change the security permissions at the root of a large file system, it takes a long time to apply the changes. I'm assuming that Windows is walking down through all files & folders, checking the inheritence flag and changing the ACL/ACE on each object.

I further assume it's done this way to improve performance - continually walking up a very deep folder structure to get the root object as that's where the permissions are inherited from would impose quite a big performance impact.

Cheers, Rob.

share|improve this question

Based on your mentioning of "folder structure" I'm guessing that you're talking about NTFS permission inheritance.

NTFS permission inheritance is, as you are surmising, actually a clever illusion that explicitly assigns "inherited" ACLs to objects at the time that the "inheritable" ACLs are modified, or that a file is created. This behaviour is considered to be flawed by some (me included). The APIs that the shell calls to change permission will cause this "walk" down a deep folder hierarchy when you change permissions at the root of such a hierarchy. (That behaviour is particularly galling when you've added a non-inheritable permission to the root of a deep hierarchy but you have to wait for the permission "walk" to complete before the shell returns control to you.)

I don't know what the rationale behind this design decision was, other than to say that the behavior preserves a degree of compatibility with older versions of NTFS, and because it was probably easier to implement the mechanism this way (fewer corner-cases). My understanding was that the Netware filesystem, for example, actually implemented real-time calculation of inherited permissions, as opposed to explicit tagging of "ineherited" ACLs like NTFS. I'd say that the Netware filesystem proves that such a realtime-calculated permission model is effectively possible to implement with reasonable performance.

share|improve this answer
Yes it's NTFS permissions. Walking back up the tree must impose some additional performance hits as more disk sectors have to be read. However, the fact that memory is reasonably cheap and abundant these days, I'm guessing that caching would reduce this overhead – Rob Nicholson Jul 25 '10 at 11:14
I can't say I've ever implemented such a thing, but I would think that, with some clever data structures and a LRU cache of recently-accessed directories it could be pulled off fairly easily. – Evan Anderson Jul 25 '10 at 20:41

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.