views:

1062

answers:

4

Hello, 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.

A: 

I'm not a python programmer but you might want to take at look at this. What your attempting to do in your programmer is very low-level. If you know C/C++ I would recommend using them instead (not because it's better, but because there might be libraries available in those languages).

Lucas McCoy
Thanks for the reply. I've written it in python, but really the language doesn't matter here, you are still going to make the same WinAPI calls. I've used python, because it is easier to test things in the python scripting environment.
shylent
True, but those WinAPI calls are most likely written in C++. I don't know much python but in C# if something is written in C++ it can be hard to include in the project without the source.
Lucas McCoy
Actually it turns out those WinAPI calls are written in C.
Lucas McCoy
+1  A: 

You can use the .Net framework

System.Security.AccessControl

This covers ACL and DACL and SACL.

Mark Schultheiss
Using .Net is out of question, unfortunately. Either way, upon examining the msdn entries on System.Security.AccessControl, I've concluded that, in essentiality, it provides no additional functionality over the C API (at least not in the area I am interested in), - my question was not about how to retrieve inheritance flags, - that is trivial, but rather about the inconsistency of INHERITED_ACE flag.
shylent
A: 

On my Win XP Home Edition this code doesn't seem to work at all :-)

I get this stack trace:

Traceback (most recent call last):
File "C:\1.py", line 37, in main(sys.argv[1:])
File "C:\1.py", line 29, in main for ace_index in range(dacl.GetAceCount()):

AttributeError: 'NoneType' object has no attribute 'GetAceCount'

Can you just try to "nudge" the DACL to be filled? I mean, if you know it's going to work after you make a slight change in it... do a slight change programmatically, add a stub ACE and remove it. Can you?

UPDATE. I made an experiment with a C# program on my work machine (with Win XP Prof) and I must tell you that the .net way of getting this security information actually works. So, when I create a new file, my C# program detects that the ACEs were inherited, while your python code doesn't.

Here is the sample output of my runs:

C:>csharp_tricks.exe 2.txt

FullControl --> IsInherited: True

FullControl --> IsInherited: True

ReadAndExecute, Synchronize --> IsInherited: True


C:>1.py 2.txt

2.txt

BUILTIN\Administrators 0x0

NT AUTHORITY\SYSTEM 0x0

BUILTIN\Users 0x0

My C# class:

public class InheritedAce
{
    public static string GetDACLReport(string path)
    {
        StringBuilder result = new StringBuilder();
        FileSecurity fs = new FileSecurity(path, AccessControlSections.Access);
        foreach (var rule in fs.GetAccessRules(true, true, typeof(SecurityIdentifier)).OfType<FileSystemAccessRule>())
        {
            result.AppendFormat("{0}  -->  IsInherited:  {1}", rule.FileSystemRights, rule.IsInherited);
            result.AppendLine();
        }

        return result.ToString();
    }
}

So, it seems to be a bug in the python pywin32 security library. Maybe they aren't doing all the necessary system calls...

Yacoder
Yeah, this definitely won't work in home edition - ntfs permissions are disabled there, as far as I know (so you are getting None as a result of GetSecurityDescriptorDacl). You are, perhaps, correct in your suggestion, that I should just use a stub ACE to sort of fix the DACLs. However, consider the fact, that I need to run this kind of code on a huge corporate file server (think, millions of objects). What if I (or you) am wrong in my assumption? What if something gets messed up? I am not going to perform writes on this kind of data unless it is absolutely unavoidable.
shylent
I can't believe your answer actually got downvoted by someone. Anyway, thanks a lot for your effort. I have no way to check if your suggestion is correct (don't have the environment), but nevertheless, it looks pretty solid to me. I will work around this problem by checking ACE against the parent object access list. Thanks for the effort, you've earned this bounty :)
shylent
Well, ACEs can be just copied to children nodes, not inherited... But if it suits your needs, I see no problem :-) Still, having these proofs you can probably submit a bug to python development...
Yacoder
A: 

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.

Gerry Hickman