A reliable way to determine if ntfs permissions were inherited

Question

I have a somewhat obscure question here.

What I need: To determine if the permissions (or, strictly speaking, a specific ACE of a DACL) of a file/folder was inherited.

How I tried to solve this: using winapi bindings for python (win32security module, to be precise). Here is the stripped down version, that does just that, - it simply takes a path to a file as an argument and prints out ACEs one by one, indicating which flags are set.

#!/usr/bin/env python
from win32security import *
import sys

def decode_flags(flags):
    _flags = {
        SE_DACL_PROTECTED:"SE_DACL_PROTECTED",
        SE_DACL_AUTO_INHERITED:"SE_DACL_AUTO_INHERITED",
        OBJECT_INHERIT_ACE:"OBJECT_INHERIT_ACE",
        CONTAINER_INHERIT_ACE:"CONTAINER_INHERIT_ACE",
        INHERIT_ONLY_ACE:"INHERIT_ONLY_ACE",
        NO_INHERITANCE:"NO_INHERITANCE",
        NO_PROPAGATE_INHERIT_ACE:"NO_PROPAGATE_INHERIT_ACE",
        INHERITED_ACE:"INHERITED_ACE"
    }
    for key in _flags.keys():
        if (flags & key):
            print '\t','\t',_flags[key],"is set!"


def main(argv):
    target = argv[0]
    print target

    security_descriptor = GetFileSecurity(target,DACL_SECURITY_INFORMATION)

    dacl = security_descriptor.GetSecurityDescriptorDacl()

    for ace_index in range(dacl.GetAceCount()):
        (ace_type,ace_flags),access_mask,sid = dacl.GetAce(ace_index)
        name,domain,account_type = LookupAccountSid(None,sid)
        print '\t',domain+'\\'+name,hex(ace_flags)
        decode_flags(ace_flags)


if __name__ == '__main__':
    main(sys.argv[1:])

Simple enough - get a security descriptor, get a DACL from it then iterate through the ACEs in the DACL. The really important bit here is INHERITED_ACE access flag. It should be set when the ACE is inherited and not set explicitly.

When you create a folder/file, its ACL gets populated with ACEs according to the ACEs of the parent object (folder), that are set to propagate to children. However, unless you do any change to the access list, the INHERITED_ACE flag will NOT be set! But the inherited permissions are there and they DO work.

If you do any slight change (say, add an entry to the access list, apply changes and delete it), the flag magically appears (the behaviour does not change in any way, though, it worked before and it works afterwards)! What I want is to find the source of this behaviour of the INHERITED_ACE flag and, maybe find another reliable way to determine if the ACE was inherited or not.

How to reproduce:

1. Create an object (file or folder)
2. Check permissions in windows explorer, see that they have been propagated from the parent object (using, say, security tab of file properties dialog of windows explorer).
3. Check the flags using, for example, the script I was using (INHERITED_ACE will NOT be set on any ACEs).
4. Change permissions of an object (apply changes), change them back even.
5. Check the flags (INHERITED_ACE will be there)
6. ..shake your head in disbelief (I know I did)

Sorry for a somewhat lengthy post, hope this makes at least a little sense.

Answer 1

You can use the .Net framework

System.Security.AccessControl

This covers ACL and DACL and SACL.

Answer 2

I think the original poster is seeing behavior detailed in

This newsgroup posting

Note that the control flags set on the container can change simply by un-ticking and re-ticking the inheritance box in the GUI.

Further note that simply adding an ACE to the DACL using Microsoft's tools will also change the control flags.

Further note that the GUI, cacls and icacls can NOT be relied on when it comes to inheritance due to many subtle bugs as discussed in the newsgroup posting.

It seems that the "old" way of controlling inheritance was to use the control flags on the container in combination with inheritance related ACE flags.

The "new" way does not use the control flags on the container and instead uses duplicate ACEs; one to control the access on the object and a second one to control what is inherited by child objects.

BUT, it seems the existing Microsoft tools (e.g. Vista) can not work in the "new" way yet, so when you make a simple change using the tools, it resorts to the old way of using control flags on the container.

If you create a new partition on Vista, then create a new folder, then look at the flags and ACEs, it will look something like this

ControlFlags : 0x8004
Owner : BUILTIN\Administrators
Group : WS1\None
S-1-5-32-544 : BUILTIN\Administrators : 0x0 : 0x0 : 0x1F01FF
S-1-5-32-544 : BUILTIN\Administrators : 0x0 : 0xB : 0x10000000
S-1-5-18 : NT AUTHORITY\SYSTEM : 0x0 : 0x0 : 0x1F01FF
S-1-5-18 : NT AUTHORITY\SYSTEM : 0x0 : 0xB : 0x10000000
S-1-5-11 : NT AUTHORITY\Authenticated Users : 0x0 : 0x0 : 0x1301BF
S-1-5-11 : NT AUTHORITY\Authenticated Users : 0x0 : 0xB : 0xE0010000
S-1-5-32-545 : BUILTIN\Users : 0x0 : 0x0 : 0x1200A9
S-1-5-32-545 : BUILTIN\Users : 0x0 : 0xB : 0xA0000000

Note the ControlFlags and the duplicated ACEs.