Using the OpenDirectoryACL Fix
Applies To: Windows 7, Windows Vista
This section includes information about using the OpenDirectoryACL compatibility fix, including the associated issues, available command-line options, and usage.
OpenDirectoryACL
The OpenDirectoryACL compatibility fix enables you to change the ACLs on a directory and to grant access to the Everyone group. This compatibility fix works by intercepting and creating a list of calls to the CreateDirectory APIs, and then changing the listed ACLs either when the application calls the ExitWindowsEx function or when the process terminates. This fix is typically applied to an application installer, as you will generally require elevated rights to change the ACLs on a protected directory.
Important
This compatibility fix should only be used if there are no other alternatives available. See the Fixing Your Code section of this topic for alternatives to using this compatibility fix.
Investigating the Issue
Both the Standard User Analyzer, a tool that is included in the Application Compatibility Toolkit, and the Sysinternals' Process Monitor can help you to detect write actions occurring in protected locations. After determining all of the problematic applications, we recommend that you perform a security review to decide the best possible fix, either redirecting the write actions to an unprotected location, running the application while elevated, or changing the ACLs.
Intercepted APIs
The following table provides a list of APIs that are intercepted by the OpenDirectoryACL fix.
| API | Description |
|---|---|
CreateDirectoryA |
Determines if the directory name matches a directory that is specified on the command line. If the directory matches, its name is added to the list of directories that require modified ACLs. |
CreateDirectoryW |
Determines if the directory name matches a directory that is specified on the command line. If the directory matches, its name is added to the list of directories that require modified ACLs. |
ExitWindowsEx |
Processes the list of directories and then loosens the ACLs prior to calling the original API. |
OpenDirectoryACL Command-Line Options
The following table provides details for each of the command-line options that are available for the OpenDirectoryACL compatibility fix.
Note
You can use environment variables in your command-line arguments. The compatibility fix will automatically expand them.
-<options> <dir-or-file>|<sddl> [ -<options> <dir-or-file>|<sddl>]....
| Option | Description | ||
|---|---|---|---|
r |
Recursively match files. |
||
m |
Match the directory part to expand to the installation directory. |
||
p |
Create an ACL for the parent directory, as well. |
||
f |
Create an empty target file, if one does not already exist.
|
||
d |
Create an empty target directory, if one does not already exist. Note You cannot use this option in conjunction with the f option.
|
||
M |
Match the directory and file parts to expand to the installation directory. |
||
P |
Create an ACL only for the parent directory. |
.gif)
NoteOpenDirectoryACL Command-Line Examples
The following examples provide guidance about using the OpenDirectoryACL command-line syntax.
Example 1
-mpr "\App Name\configuration\*"
This example loosens the ACLs on all child directories of the %ProgramFiles% \appName1\configuration\* directory, including the parent and recursively including all child directories.
Example 2
-d "%CSIDL_PROGRAM_FILES_COMMON%\App 2"
This example loosens the ACLs on the %ProgramFiles% \appName2 directory, in addition to creating this directory if it does not already exist.
Example 3
-mp \app3\*|D:P(A;OICI;CCSWWPLORCFRFX;;;AU)(A;OICI;FA;;;BA)(A;OICI;FA;;;SY)
This example loosens the ACLs on the program files in the \appName3 directory and its parent directory, setting the ACLs according to the provided Security Descriptor Definition Language (SDDL).
Fixing Your Code
We suggest the following fixes to your code:
Modify or create your applications so that they run as a Standard User.
Implement a separate executable (.exe) file that can appear on a manifest as requireAdministrator for any application updates.
Store your shared application data in the common application data area and configure the ACLs at the time of installation.
Store your writeable files in a per-user area, assuming that there is no business reason for the information to require shared write access.
Alternatives to the OpenDirectoryACL Fix
There are three known alternatives to using this compatibility fix. However, each option has its own drawbacks. You must determine which solution works best for your organization.
Option 1: You can redirect the application to write to an unprotected location. However, this fix might cause additional issues because the redirection is a per-user action, instead of a per-computer action. Additionally, if the files are accessed from multiple executable (.exe) files, then each of the files must be fixed to point to the new, unprotected location.
**Option 2:**You can apply the RunAsAdmin compatibility fix to the application. This fix elevates the application so that protected file writes are allowed. However, this will prevent a standard user from using the application and will make the experience suboptimal for administrators, as each launch will require an elevation prompt.
**Option 3:**This final option only applies if you are in an enterprise environment and you deploy your applications by using deployment software. In this situation, we recommend that you modify the ACLs by modifying or transforming the installation itself, instead of applying the fix to the installation software.