How to Set Directory Permissions at Install Time using an MSI Created Using Windows Installer XML (WIX)

Original Link: 

http://blogs.msdn.com/b/cjacks/archive/2008/12/04/how-to-set-directory-permissions-at-install-time-using-an-msi-created-using-windows-installer-xml-wix.aspx

Author:　Chris Jackson

Following content is directly reprinted from above link and only for knowledge sharing. Please go to above link for more detailed info. Thanks~

Here is a topic I have been saying “I’ll get to it” for a while now…

We’ve talked a lot about UAC here, and I have really stressed the point that standard users shouldn’t be able to affect other users or the machine itself, and if you want to violate that rule then you need to do so explicitly.

The one area that I’ve received some questions on is what to do about shared user data. You should be using c:\programdata (not hard coded, of course!) to put your shared user data into, and then explicitly setting the ACL. You’ll need elevated permissions to set that ACL, so you should be doing so at install time.

Now, here’s the part that makes people nuts (and rightly so!) – we then never bother to tell you how you can set that at install time! At best, we’ll give you some hints. Want to know something interesting? You’d probably be surprised at how many people don’t know how to do this themselves, but nonetheless will happily tell you that it’s what you ought to be doing.

I think that’s kind of rude, so I figured I’d actually spend some time poking around so that when I tell you to do it, I could then answer the follow-up question of, “OK then, how?”.

Of course, installers could be anything, and I don’t know all of the tools (not by a long shot). I’ve never been a packager. I had to pick something, though, so I picked what I thought was best – an MSI. If you’re writing arbitrary code (or a custom action) you can just use the Windows APIs directly to set up the security descriptor. But you actually get OK (note I didn’t say “great”, or even “good”) support from the Windows Installer framework.

But how should I build the MSI? I prefer WIX. One comment talks about using the Visual Studio Setup and Deployment Project. I recommend you do not pass go and do not collect $200 until you install WIX instead. It’s not quite as simple, but it actually exposes the power of the platform instead of simplifying it by not letting you actually use the whole thing.

So, here’s the XML I wrote for WIX to create a folder (which I have to do explicitly since I made an empty one) and set the ACL to allow the Everyone group full control of this folder:

<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
  <Product Id="1cf0f45f-3a04-4878-becc-6f6b4331bfb6" Name="InstallerDirectoryPermissions" Language="1033" Version="1.0.0.0" Manufacturer="InstallerDirectoryPermissions" UpgradeCode="f9a6c7b0-6ed9-4b46-9db1-653eeb568236">
    <Package InstallerVersion="200" Compressed="yes" />
    <Directory Id="TARGETDIR" Name="SourceDir">
      <Directory Id="CommonAppDataFolder">
        <Directory Id="MySharedFolderId" Name="MySharedFolder">
          <Component Id="SharedFolderComponent" Guid="84A264EF-2BC5-41e3-8124-2CA10C2805DB">
            <CreateFolder Directory="MySharedFolderId">
              <Permission User="Everyone" GenericAll="yes" />
            </CreateFolder>
          </Component>
        </Directory>
      </Directory>
    </Directory>
    <Feature Id="FolderPermissions" Title="InstallerDirectoryPermissions" Level="1">
      <ComponentRef Id="SharedFolderComponent" />
    </Feature>
  </Product>
</Wix>

If you compile this to create an MSI, and then edit it with Orca, you’ll see the entries in the Directory, CreateFolder, and LockPermissions tables that make all of this magic happen.

Now, remember how I said that the support was just OK? Well, have a look at what we put into the Permissions entry (which ends up in the LockPermissions table) – it’s just plain English. Well, you’re the one responsible for localizing this. From the docs:

“User - The column that identifies the localized name of the user for which permissions are to be set.”

Why did I choose the Everyone group? Because it’s special cased: “The common user names ‘Everyone’ and ‘Administrators’ may be entered in English and are mapped to well-known SIDs.” (Please note: I don’t speak any other languages, so I don’t have any localized versions of Windows installed – feel free to correct me if you do and I have misinterpreted this!)

But if you just wanted to target users, or domain users, or some other group, and you support multiple languages, you’ll want to do that work inside of a custom action (“A custom action is required to enter the localized name of any other user or group.”). Unless, of course, you already have that value in a property, such as the LogonUser property.

Hopefully this helps you sort out how to do it, instead of us just telling you to “go look it up.” Because you probably have enough to do already.