Powershell - setting a directory permission to propagate, but permissions not picked up by children

Answered Powershell - setting a directory permission to propagate, but permissions not picked up by children

  • Sunday, June 10, 2012 5:59 PM
     
     

    When I set a new filesystemaccess rule with powershell and set-acl, I set the inheritance flags to propagate to children and leaf objects

    $acl.AddAccessRule((New-Object System.Security.AccessControl.FileSystemAccessRule("username","FullControl", "ContainerInherit, ObjectInherit", "None", "Allow")))

    Set-Acl -path $filename -aclObject $acl

    When I look at the permission in explorer.. in the security tab.. advanced.. the propagation is set correctly. But if I look at the children themselves, they do NOT show the new security rule.

    If in explorer, I add another rule with a different SID.. and save it (without forcing the option to 'replace all child object permissions...'). Then both the manual, and the powershell rule shows up on the children. Its as if there is some sort of kickstart needed to cause the children to pick up the new propagated rule. What am I missing to make the child objects show the new rule added?

All Replies

  • Sunday, June 10, 2012 6:04 PM
     
     

    Future children will get set.  Inheritance is inheritance and propagation is propagation.  They are no the same thing.

    An object inherits from its parents.  A parent container propagates to its children.  A file does not have children. Only containers can propagate.

    Note that a propagation setting of 'None' indicates "This folder only".


    ¯\_(ツ)_/¯


  • Sunday, June 10, 2012 6:22 PM
     
     

    I get file does not have children.. but this is a directory I'm setting the ACL on.  The variable name is poor because I was copy/pasting code into a test.  But it is a directory I'm modifying.  The children permissions right now are only from the parent and not editable on the child.

    Excuse if I'm abusing the terms wrong..

    But if I try to set the propagation flags as such on the directory

    $acl.AddAccessRule((New-Object System.Security.AccessControl.FileSystemAccessRule($RoleUserGroupNames["certOSAuditors"],"FullControl", "ContainerInherit, ObjectInherit", "InheritOnly", "Allow")))

    It still doesn't work

    What I want is just the same as you do in explorer.. add a permission to the directory, and it's automatically reflected, WITHOUT using 'replace child object..' permissions.

    If I do as in the original post.. yes, new children created do get the permission... but existing objects which are set to inherit, do not get them immediately.

    If I do it via explorer, the existing children get the new permission immediately.  If I do it as in the original post, and then add an additional user via explorer, existing children get BOTH permissions immediately.


    • Edited by skapinos Sunday, June 10, 2012 6:35 PM
    •  
  • Sunday, June 10, 2012 6:49 PM
     
     

    I get file does not have children.. but this is a directory I'm setting the ACL on.  The variable name is poor because I was copy/pasting code into a test.  But it is a directory I'm modifying.  The children permissions right now are only from the parent and not editable on the child.

    Excuse if I'm abusing the terms wrong..

    But if I try to set the propagation flags as such on the directory

    $acl.AddAccessRule((New-Object System.Security.AccessControl.FileSystemAccessRule($RoleUserGroupNames["certOSAuditors"],"FullControl", "ContainerInherit, ObjectInherit", "InheritOnly", "Allow")))

    It still doesn't work

    What I want is just the same as you do in explorer.. add a permission to the directory, and it's automatically reflected, WITHOUT using 'replace child object..' permissions.

    If I do as in the original post.. yes, new children created do get the permission... but existing objects which are set to inherit, do not get them immediately.

    If I do it via explorer, the existing children get the new permission immediately.  If I do it as in the original post, and then add an additional user via explorer, existing children get BOTH permissions immediately.


    NO - don't worry .,  I understand that children do misbehave often. 

    NO - youare not abusing the terminology wrong you are just using it incorreclty which may prevent you from understanding what teh flags acutally do.

    In the folder directly under the folder you have st teh permissions on righ-click and FILE and check the permissions.  They will be set correctly.  I suspect you are only looking at the folder settings which will not be set.  That is what "None" means.

    None means no inheritance of any kind is propagated.  Only the immediate folder contents are  affected.

    This may also have an issue if you are not the owner of the obejcts in the folder or if you do not have 'Full Control' of the objects.


    ¯\_(ツ)_/¯

  • Sunday, June 10, 2012 9:41 PM
     
     

    I'm not sure I'm communicating the problem because the flags are correct from what I see from MSDN and from what you see in explorer.

    The Scenario is  ParentDir, and Childfile1, Childfile2, etc.

    The files are set to inherit permissions... they take any permissions from ParentDir immediately when a permission is set or modified on ParentDir via windows explorer. 

    If you look at ParentDir's permissions, for each access right under 'applies to'  it has 'this folder, subfolders, and files'.  This is the baseline behavior.

    When you use FileSystemAccessRule("username","FullControl", "ContainerInherit, ObjectInherit", "None", "Allow")  the resulting permission looks IDENTICAL in ParentDir to the other permissions and under 'applies to' has 'this folder, subfolders, and files' listed.

    If the flags set the accessrule on ParentDir are wrong... why does it say  'this folder, subfolders, and files' under 'applies to'?  The files are not be modified at all in this exercise.

    And adding the confusion is why the new right does show up on the files without modifying the rule.. if you change any other rules.  That would infer the rule was correct to start with.

    At no time am I using the replace permissions on child objects option in explorer either.

  • Sunday, June 10, 2012 10:10 PM
     
     

    If I set 'None" as te h propagation flag then folders do not get the settings but files do assuming I have sufficient provileges to change teh file security.  If I do not have fullcontrol or owner ship of teh files then I cannot propagate the setting onto the file even if the file is already receiving inherited settings.  My (your) account cannot propagate onto a file that you do not have sufficient provileges on.

    The only other isseu is that you can have a currupted DACL and things may then go wrong.  Some disjk issues will also cause ire.

    To test.  Create a brand new file under the folder you are trying to set.  Set the DACL for the parent  then check the file you just created.  You should be the owner of the file and have 'Full Control'.

    If this still fails create a new folder and a new file and set a new ACE on teh folder and check the file.

    If this continues to fail then try running CHKDSK.

    It is possib;e with repeated writing of ACLs to screw up the security descriptors.  Tis can aslo happen if the folders were moved over from W2K,  W2K set up the SDs differntly and they will fail if the ACEs are out of order.  This wsa fixed in an SP but some ACLs may still be damaged or out-of-order.

    I am certian there are other things that can go wrong.  I suspect that new OSs might also have some hidden gotchas.


    ¯\_(ツ)_/¯

  • Tuesday, August 14, 2012 3:45 AM
    Owner
     
     Answered
    There are a number of edge cases involving Set-ACL that produce unexpected results. You may want to review some of the ones listed on TechNet here. In general, I use Set-ACL for very simple permissions setting, such as using Get-ACL to copy permissions from one file to another one. For more complex scenarios, I generally use ICACLS which is a great tool. You can use WMI, but things get really complicated very quickly. By far, the easiest tool to use when dealing with setting security is ICACLS.