Modifying Directory ACLs with the OpenDirectoryAcl Shim

I received a request to talk about a particular shim. And yes, I received that request over a month ago, so ... sorry about that. Nonetheless, I've managed to scratch out a little niche of time to discuss the shim:


Yep, this does exactly what you would expect it does, modifying the ACL on a directory. I had not documented this shim yet because in a typical enterprise environment, it typically is not the best approach to resolving application compatibility issues.

But, that does not mean that it is never useful, so rather than just ignoring it, I will simply go through the steps I would normally go through to eliminate the need for this shim, and allow my eminently gifted readers to re-use or modify the logic as it suits them.

Can you redirect the file write?

If I can redirect the file write to a less privileged location, then I prefer to do that. By doing so, I don't have to loosen the security profile of the system. Even if I need to share the file, I generally prefer to take writes out of Program Files and instead set something up (ACL'd appropriately) in ProgramData, so I will sometimes redirect even if I am changing directory or file permissions.

Should the application run elevated?

If the purpose of the application is to modify protected resources, it may be a better choice to require elevation rather than to remove the protection on the resources.

Can I modify the ACLs when I repackage?

If I have decided that I need to loosen the ACL. First, I re-read Changing access control on folders vs. files and think again - am I really sure I need to modify the ACL?

Let's say that I have some compelling reason to change permissions on the file or directory. Since most enterprise software is deployed using management software, such as System Center Configuration Manager, rather than simply waiting for user's to self-launch an executable file, then I would approach that by repackaging or transforming the installer (frequently an MSI) rather than shimming a setup.exe. The LockPermissions table in an MSI allows me to set ACLs. (If you're writing the installer using the fabulous WIX tool, then you can use the Permission Element.)

There are simply almost no situations where I find users self-installing setup.exe files. However, in the consumer space, this is extremely common, which is why this shim works well in that scenario and we see this bubbling up as the 11th most commonly used shim in the system shim database.

How OpenDirectoryAcl works

Why do you need to target the setup? Because that's when we apply the ACLs. Specifically, we intercept calls to the CreateDirectory APIs, and if you create a directory that matches the command line, then we put it in the queue to modify that ACL. Then, when we either call the ExitWindowsEx API or exit the process, we apply the ACL changes that were matched. That means you are modifying ACLs on directories when you create them, so you have to target the setup.

So, I think you can see now why I have never once had to use this with an enterprise customer. But just because I haven't doesn't mean you won't.

Configuring OpenDirectoryAcl

If you've gotten this far, well, let's configure this shim. The command line syntax is as such:

-<options> <dir-or-file>|<sddl> [ -<options> <dir-or-file>|<sddl> ...]

The options you can specify are:

  • r - recursively match files
  • m - match the directory part to expand to the installation directory
  • M - match the directory / file parts to expand to the installation directory
  • p - ACL the parent directory as well
  • P - ACL the parent directory only
  • f - create an empty target file if it does not exist (do not combine with "d")
  • d - create an empty target directory if it does not exist (do not combine with "f")

You then specify the directory or file you want to modify the ACL for. (Yes, the name of the shim is deceiving, because you can specify a file rather than a directory.) If the file name has spaces, then make sure you enclose the file name in quotes, as spaces are a delimiter for the command line. Also, if you use environment variables.

Finally, you don't need to specify SDDL. By default, you'll receive D:(A;OICI;FA;;;BU)

However, you can specify SDDL if you want. after the directory or file path, simply include a pipe character ( | ) and then include the SDDL you'd like to add.

Ask me about this, or other shims, at TechEd 2008

I have two sessions on Shims set up for TechEd 2008, and I invite you to come and chat with me there. Also, I am in the running to be part of a Windows Vista Bloggers' Panel hosted by Mark Russinovich at TechEd IT Pro week. Come and barrage the panel with your most challenging questions - it should be a great time for all. There is still time to register - head on over to to register.

Comments (11)

  1. Ken says:

    It almost seems as though you are implying the SHIM adjusts the ACLs for the entire directoryfile objects entirely, as opposed to just the file as you defined within the SHIM collection fix?

    My thoughts are if you specify your SHIM to implicitly define to an exe file, then explicitly only allow it access to it’s own foldersfiles.. security really isn’t horribly compromised so long as your SHIM is defined tightly enough to prevent falsifications of the exe it is tied to.

    Where this is coming up is for a legacy application which will not be updated any time soon, but more likely replaced. The programmers who designed and implemented it back in the days have long since decayed with the dinosaurs. The applications were written for "self updating" functions, which require that the self updating exe have some enhanced permissions to the folders they reside in for filedirectory creationmodification.

    The hope I was having was to use this OpenDirectoryACL to enable this function to have the rights to the folder, but ONLY the folder, and ONLY for this singular exe that does the update functions.

    Am I misunderstanding this?

  2. cjacks says:

    It opens the entire directory ACL. Most commonly, you’d apply it to a setup.

    There is no notion of a per-process ACL. We couldn’t modify it when you launch the process without elevating, in which case we may just as well elevate the entire process and not use the shim. I understand what you’re hoping for, but there is no way to implement something like this securely.

    I tend to prefer redirection to loosening ACLs, I just talked about this one in response to a request.

  3. Ken says:

    Eeek… My assumption (and yes, my bad) was that in defining a SHIM to be applied per application… was that the shim would apply per application. Otherwise to be honest… why use a SHIM at all, just blow the permissions wide open during the installer with an ACL set and call it a day (although you do get the permissions to remove the fix using addremove does it then mark the folder to "inherit permissions" if you do so, or does it return it to how it was before if it had been customized).

    It’s a little disconcerting I think to have each FIX applied per application (using the ACT tools), when it ends up being for the entire machine and all applications. How many other SHIMs apply the same way becomes a question that raises some security concerns regarding using SHIMs for application remediation in a Vista deployment.

    To you it likely makes perfect sense understanding the underlying reasons behind why each one can only perform certain actions in regards to individual files, but to those of us using the tools to remediate as a minor deployment effort. This can be a bit confusing. =

    Appreciate all the time here though… learned a lot from your BLOGs so far in this.

  4. cjacks says:

    Hi Ken,

    This shim is a bit different than most, and it’s not something I’ve ever used in an enterprise because, as you point out, you can just repacage as you need to. We apply it to commercial software, specifically to commercial setup.exes, because we can’t repackage it. Somebody pops a CD in, and this will fix it up while it’s elevated. We use it as a last resort – we prefer to redirect to less privileged locations (typically CorrectFilePaths) but sometimes you need the semantics of shared machine data for the application to work.

    Fixes are applied per application – this one just happens to be applied to a setup application, which also happens to be elevated by virtue of being a setup, so it has more permissions than the average application and we can do something like this.

    Because of the way shims are implemented, they can’t do anything your application couldn’t do (because they sit outside of Windows also). It’s not as if this loosens ACLs while running as a standard user – you can only have it work while you’re running elevated.

    Make sense? I’m happy to go on, and I talk specifically about security in my presentations at TechEd and other conferences.



  5. ABC says:

    Hi, I am new to this ACT and Shims. But I have some idea how to apply the shims. I just wondered once I applied this OpenDirectoryACL shim to one exe. But after I tried to access that folder, still I am not able to access the folder( am gettin the permission denied error as like earlier).

    Do I am doing anything wrong here?( only selecting the exe and applying this shim is enough?) ..please anyone could you tell me the steps how to apply it?

  6. cjacks says:


    As the article indicates, you have to be both elevated and shimmed during the original CreateDirectory call. If it’s not working, then one of these is likely not true – you’ll have to figure out which one.


  7. ABC says:

    Hi Chris,

    Thanks for your reply. As I am new to this shims concept, not able to catch your high level terminology. Please could you give me the guidance like how to apply it from Compatability Manager.( I know it’s really hectic to explain in spoonfeeding manner).

    Here we opend the Compatibility Manager and  selected the EXE & chosen the Shim, but even there is one more filed called "PARAMETERS". Do we need to provide any inputs here to get apply this shim.?

    Please guide me, other wise I would be in trouble. It’s very urgent to me.

  8. cjacks says:

    ABC –

    I have a lab posted at – probably easier for you to go through that because it has the step by step with screenshots. Hope this helps!



  9. ABC says:

    Hi Chris,

    Thanks for your quick response. I tried to open the above mentioned link, But it was keep on loading the screen for a long time and I have not seen the response even after 1 hour also.

    Please could you help me, how can I watch the live demo?. Is there anyother alternative ways do you have?.


  10. cjacks says:

    I just tried again, and it worked fine. You can also search for mitigating with shims to find the lab.

  11. ABC says:

    Hi Chris,

    ya, it was working fine and I could able to follow whole session. thnks once again


Skip to main content