I need to vent a little before I get into the code.  Had a frustrating one today!  All because of unclear documentation in MSDN’s published library of their .NET classes. I guess it’s true what they say, that sometimes you should listen to what isn’t said.

I had to build a work-around to a problem with an MSI from a certain cardiovascular imaging software.  It seems the MSI wants to strip the permissions for the local “Users” group off of the C:\ProgramData folder.  Not cool!  At first the vendor tried to brush it under the rug and gave me a few lines about the development process, blah, blah (develoment?!  you’re just fixing the installer!) and then said it could take 10-12 weeks (which is further out than our very-rushed go-live) and if I could just work around it.  Did I mention this isn’t a lesson in customer service skills?

So anyway, I sat down to figure out how I was going to do it.  I’ve lost a lot of my VB skill because I haven’t used it in over 6 months and I’ve been learning a lot of Powershell.  I love Powershell and I’ve already written code to modify permissions (on a file on XP) so I figured this would be easy.  The one good thing I had going is the issue is only affecting Windows 7 so running the Powershell script locally isn’t a problem (we never pushed PS out to our XP devices).  What I thought would be a 5 minute mod of my existing code turned out to be about 30-40 minutes.

It seems just supplying the user/group (IdentityReference),  read/write/etc (FileSystemRights), and Allow/Deny (AccessControlType) were enough… but not really.   Mine was set to:

$Ar = New-Object  system.security.accesscontrol.filesystemaccessrule("Users","ReadAndExecute","Allow")

When setting just those three properties the permissions got applied but if you right-clicked on the folder and viewed the Security tab of the folders properties you saw a blank list of rights for that user/group.  All except for “Special Permissions” at the bottom.  If you went into advanced and dug a little deeper you could see that the Traverse folder/ execute file, List folder/read data, Read attributes, and Read extended attributes were all selected.  Read permissions was not.  Kind of a problem.  Below is what that looked like.

The other problem is it says “Apply to:  Subfolders and files only”.  With the changes not applying to the root folder I actually made the changes on, and not having proper read permissions, I have a funky looking ACL.  The odd thing is that the permissions I was wanting to apply worked.  Someone who fell into the “Users” group was able to read and execute like I wanted.  But, it’s technically broken so it needed to be fixed.

So I called up the MSDN library to find out what else I might need.  This post is already longer than it needs to be so it will suffice to say that I fiddled around with the InheritanceFlags Enumeration and PropagationFlags Enumeration parameters for quite a while.  I assumed the the FileSystemRights could be comma-separated since there were many options and you could have multiple.  I tried that and it worked, I got the “Read Permissions” checkbox back on the advanced properties view.   Still, the ACL was blank on the Security tab (with the exception of Special Permissions).  that took setting the Inheritance and Propagation flags correctly.  Both of these flags apply ONLY to the child object.  They do not affect whether the folder you are making changes to will inherit from it’s parent.  Inherit determinse whether the child object(s) inherit from the folder you are making changes on and propagate is what it pushes them down to.  Propagate is dependent on Inherit.

Ok, finish this up already.  Since I needed to put permisions back to default so that All Users/Public can appropriately access that folder I needed both file and folders to inherit.  And the kicker (reading what isn’t said…) is that the Propagation flags have to be set to None.  Why?  Because it doesn’t mean it wont propagate, it means it’s going to use the default value for propagation, which is:  This folder, subfolders, and files!  But the documentation does not say that anywhere!  It finally dawned on me that, that is what it would do.  So, my final code for adding “Users” to the ACL for the C:\ProgramData folder with Read and execute, List folder contents, and Read permissions is:

$Acl = Get-Acl C:\ProgramData
$Ar = New-Object  system.security.accesscontrol.filesystemaccessrule("Users","ReadAndExecute,Read","ObjectInherit,ContainerInherit","None","Allow")
$Acl.SetAccessRule($Ar)
Set-Acl C:\ProgramData $Acl

Line 1 I’m getting the ACL of the object I want to modify
Line 2 I’m creating a new access rule and setting all of the parameters.  The local Users group, the TWO FileSystemRights, the Inheritance Flags (so that folders and files inherit), the Propagation flag (none means use default), and finally that I”m Allowing access and not Denying.
Line 3 I’m taking that access rule and adding it to the ACL object I created from the folder
Line 4 I’m actually setting the new ACL [in stone]

Yes, all that for 4 lines of code.

“Special” thanks to the MSDN library:  http://msdn.microsoft.com/en-us/library/system.security.accesscontrol.filesystemaccessrule.aspx

You must be logged in to post a comment.