Recursing filesystem to change inherited permissions
Why is it that when I change NTFS permissions on a directory, Windows recurses over each and every subdirectory and file below that directory? I thought permissions could be inherited! It seems as though, even though permissions are logically inherited, that on a physical (filesystem metadata) level they are not, and that therefore in order for changes to inheritable permissions to take effect on existing files, child objects in the filesystem have to be given the inherited permission explicitly in their ACLs. Often I end up having to wait over 10 minutes for this ideally needless exercise. Should not instead the OS simply check ACLs on all parent directories up to the root when performing accesses, thereby fixing this horrendously slow permissions changing operation? Certainly in a naive implementation this would slow down file access, which I understand is worse than slowing occasional permission changing operations; however, a smarter implementation would cache the effective ACLs of directories so that in practice the difference would be negligible.
September 28th, 2012 7:09am

1000 users poking through a file server generates plenty of ACL reads, my guess it's probably better to be indexed upfront for speed later. This is the kind of thing I'd run over-night via scheduled task so that there isn't a 10 minute hit during production hours. Don't forget to mark your posts as answered so they drop off the unanswered post filter. If I've helped you and you want to show your gratitude, just click that green thingy.
Free Windows Admin Tool Kit Click here and download it now
September 28th, 2012 7:31am

1000 users poking through a file server generates plenty of ACL reads, my guess it's probably better to be indexed upfront for speed later. This is the kind of thing I'd run over-night via scheduled task so that there isn't a 10 minute hit during production hours. Don't forget to mark your posts as answered so they drop off the unanswered post filter. If I've helped you and you want to show your gratitude, just click that green thingy.
September 28th, 2012 7:31am

I agree that we don't want to incur a significant performance hit on the more frequent accesses. However I still think there are better ways the OS could handle this. For instance, there could be a "permissions dirty" marker in the directory entry, which informs the filesystem driver that permissions on the directory have changed and not yet been injected into child objects. Since the filesystem must pull in directory entries anyway (unless it somehow flattens paths), the cost of checking for this mark is negligible. Then the system could inject the inherited entries in the background and clear the marker once it's been done, to restore the quicker ACL checks. I develop software so I do understand there are some added complications here due to concurrency and resilience, but these things can be handled. I also still have to wonder if just caching the parent ACLs might be a better option. Admittedly if there are a huge number of non-terminal objects in the filesystem which are frequently referenced, then caching parent ACLs is going to suffer, but then again storing parent ACLs redundantly in all the child objects will start to suffer as well in terms of disk space and (perhaps more importantly) I/O required to pull in all those larger ACLs. So there seems to be at least some case for caching them instead of storing them redundantly. Good idea to save up permissions changes and run them at a quiet time. Remember though that not all systems have uniform quiet times. (For instance, in a render farm in an animation studio, nodes do not require human intervention and can often be actively working 24/7.) Cheers, Kevin
Free Windows Admin Tool Kit Click here and download it now
October 7th, 2012 1:34am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics