What does it mean when the Advanced Security Settings dialog says that an ACE was inherited from "Parent Object" without naming the specific parent?


The Advanced Security Settings dialog shows the ACEs in an object's ACL, and one of the pieces of information is a column labeled Inherited from which identifies whether the ACE was inherited, and if so, from where. A customer observed that when they opened the Advanced Security Settings dialog, one of their objects had an ACE that showed Parent Object as the Inherited from.

Name: C:\dir1\dir2\dir3\dir4\file
Type Principal Access Inherited from Applies to
Allow Administrators Full control None This folder only
Allow Administrators Full control C:\dir1\dir2\ This folder, subfolders and files
Allow SYSTEM Full control C:\dir1\dir2\ This folder, subfolders and files
Allow CREATOR OWNER Full control C:\dir1\dir2\ Subfolders and files only
Allow Users Read & execute C:\dir1\dir2\ This folder, subfolders and files
Allow Users Special C:\dir1\dir2\ This folder and subfolders
Allow Authenticated Users Full control Parent Object This folder, subfolders and files

However, when they went to the parent object C:\dir1\dir2\dir3\dir4, that ACE is nowhere to be found.

Name: C:\dir1\dir2\dir3\dir4
Type Principal Access Inherited from Applies to
Allow Administrators Full control None This folder only
Allow Administrators Full control C:\dir1\dir2\ This folder, subfolders and files
Allow SYSTEM Full control C:\dir1\dir2\ This folder, subfolders and files
Allow CREATOR OWNER Full control C:\dir1\dir2\ Subfolders and files only
Allow Users Read & execute C:\dir1\dir2\ This folder, subfolders and files
Allow Users Special C:\dir1\dir2\ This folder and subfolders
Allow Everyone Full control C:\dir1\dir2\ This folder, subfolders and files

How can an ACE be inherited from its parent, when it doesn't exist in the parent?

The Advanced Security Settings dialog is trying to be helpful, but in doing so, it implies a greater level of confidence than it actually offers.

ACEs do not specify where they were inherited from. There is merely a bit in the ACE called INHERITED_ACE which means, "This ACE was created via inheritance." Not only does this bit not tell you where the ACE was inherited from, but the bit might even be wrong! Anybody can go in and toggle the bit, and bingo, you now have forged the "I was created via inheritance" flag. Another way this flag could be out of sync is if the user started an ACL update operation and then canceled it partway through.

The Advanced Security Settings dialog uses the Get­Inheritance­Source function to determine the source of each ACE. That function walks up the parent chain looking for matching inheritable ACEs. If a match is found, then the Advanced Security Settings dialog shows that parent as the Inherited from. Otherwise, it shrugs its shoulders and says Parent Object.

The string Parent Object means "This ACE claims to have been inherited from somewhere, but I can't figure out where, so I'm just going to be vague and say that it came from some parent object somewhere." Perhaps a less confusing string would have been Ancestor Object or even simply Unknown.

The Advanced Security Settings dialog figured that it would go the extra mile and instead of merely saying Inherited = Yes, it would try to find a parent object that was the most likely source of the inheritance. But by doing that, you came to expect it, and then you got upset when it wasn't able to come through for you. No good deed goes unpunished.

Comments (8)
  1. Joshua says:

    Also, inheritance is wrong when the file has more than one link.

  2. wqw says:

    The real fun starts when the folder is actually a junction.

  3. Antonio Rodríguez says:

    @Joshua: AFAIK, it can not happen, at least not in Windows. File permissions are checked at opening time (during the call to CreateFile – that's what the dwDesiredAccess parameter is for). And CreateFile has the full path to a file, including junctions and the exact link to it. So CreateFile can solve permissions at the link level.

    Common sense dictates that links to the same file should have the same permissions, as they are protecting the same object. But if you create two links to the same file and assigns them different permissions, well, then you can not complain of the ambiguity :-) .

  4. alegr1 says:

    Inheritable permissions are applied to the object at the creation time, not at the open time. When you create a hardlink, it doesn't change the existing ACL of the existing file. Any inheritable ACLs of the parent directory of the new hardlink do not apply to the file.

  5. Engywuck says:

    @Antonio: I just created a file D:1test1.txt and made a hardlink to D:2test2.txt. Then I added inheritable permissions on folder "1". The file "test2.txt" in folder "2" inherited the permission set on folder "1", and when opening the Advanced Security Settings on "D:2file2.txt" it showed this permission as originationg from "parent object", although in "D:2" this exact setting was not set. Afterwards I added *other* inheritable permissions in folder "2", which resulted in the file (in both folders) having these, but no longer the ones inheritable from "1".

    Looks like "Parent Object" in this case means "the parent object last changed" – not necessarily of the path you "went through" to open it.

    This is quite logical when the ACEs are saved with (in?) the file object, which has the advantage of not having to "calculate" the resulting set of permissions on every access – and of course having the same permissions for the same object, independent on the link to it. That's also why changing permissions on a folder with many file system objects "beneath" it takes a while.

    Tests with junctions are left as exercise for the reader :-)

  6. AbstractSpoon says:

    >> No good deed goes unpunished.

    The road to hell is paved with good intentions!

  7. Henke37 says:

    *Anyone that can edit the ACE that is.

  8. Neil says:

    So "Parent Object" really means "Error"?

Comments are closed.

Skip to main content