WIX: Giving Permissions to a folder

问题:

I've read all related topics and haven't found a full answer to my problem.

I would like to give full permissions to SYSTEM and Read & Execute permissions to Users group to a folder under Program Files. Nothing more, nothing less.

I know there are 3 ways to give permissions to a folder using WIX, none of them are really good for me and I'll explain why:

1) Regular Permission element:

    <CreateFolder Directory="Test">
      <Permission User="SYSTEM" GenericAll="yes"/>
      <Permission User="Users" Domain="[LOCAL_MACHINE_NAME]" 
      GenericRead="yes" Read="yes" GenericExecute="yes" ChangePermission="yes"/>
    </CreateFolder>

Problem: It fails on foreign OS since it doesn't knows the "Users" keyword. I tried it with SID as well. Beside that I need to place the Permission element under each file in the Test directory (but if this was the only case, I would have managed)

2) WixUtilsExtension PermissionEx element:

    <CreateFolder Directory="Test">
      <util:PermissionEx User="SYSTEM" GenericAll="yes"/>
      <util:PermissionEx User="Users" Domain="[LOCAL_MACHINE_NAME]" 
      GenericRead="yes" Read="yes" GenericExecute="yes" ChangePermission="yes"/>
    </CreateFolder>

Problem: The folder also keeps the default permissions of the Program Files folder. I can not allow that.

3) PermissionEx with Sddl:

Problem: This element is only available when installing with MSI 5.0. I'm using installer 3.01.

I'll be happy to get any solution, including solutions with custom actions...

回答1:

Use the following code to accomplish this without a custom action. I've verified this works (also on child folders). Also the User Everyone is mapped on localized windows operating systems.

<CreateFolder>
      <Permission User="Everyone" GenericAll="yes" ChangePermission="yes"/>
</CreateFolder>

回答2:

I had this exact same issue and talked to Rob M about it. I was going to do Christian G's answer (https://stackoverflow.com/a/5296967/18475), but Rob suggested using WixQueryOsWellKnownSID (http://wix.sourceforge.net/manual-wix3/osinfo.htm) to get around non en-US locales.

In the .wxs file you add the following:

<PropertyRef Id="WIX_ACCOUNT_LOCALSYSTEM" />
<PropertyRef Id="WIX_ACCOUNT_USERS" />

And further down in the .wxs file where you want to apply the permissions it's just like this:

<Permission GenericAll="yes" User="[WIX_ACCOUNT_LOCALSYSTEM]" />
<Permission GenericRead="yes" GenericExecute="yes" User="[WIX_ACCOUNT_USERS]" />

Now when you run light, you just need to link WixUtilExtension.

light -ext WiXUtilExtension ...

NOTE: Depending on your version of WiX, this may not be fully supported. If it doesn't work for you, there may be other options you can use to translate SIDs.

回答3:

Another option would be to have a simple CA that will just translate a msi property that contains the SID to the actual name of the group from the localized OS. The CA doesn't have to be deferred and it's not doing the actual work of setting the permissions.

Below is a sample of CA that reads the value of PROPERTY_TO_BE_TRANSLATED msi property and translates the msi property indicated by it. In this way you can run the CA to translate different msi properties.

 [CustomAction]
  public static ActionResult TranslateSidToName(Session session)
  {
     var property = session["PROPERTY_TO_BE_TRANSLATED"];
     if (String.IsNullOrEmpty(property))
     {
        session.Log("The {0} property that should say what property to translate is empty", translateSidProperty);
        return ActionResult.Failure;
     }
     var sid = session[property];
     if (String.IsNullOrEmpty(sid))
     {
        session.Log("The {0} property that should contain the SID to translate is empty", property);
        return ActionResult.Failure;
     }
     try
     {
        // convert the user sid to a domain\name
        var account = new SecurityIdentifier(sid).Translate(typeof(NTAccount)).ToString();
        session[property] = account;
        session.Log("The {0} property translated from {1} SID to {2}", property, sid, account);
     }
     catch (Exception e)
     {
        session.Log("Exception getting the name for the {0} sid. Message: {1}", sid, e.Message);
        return ActionResult.Failure;
     }
     return ActionResult.Success;
  }

In WiX you define the properties to be translated using the SID for the accounts:

  <Property Id="AdminAccount" Value="S-1-5-32-544" />
  <Property Id="EveryoneAccount" Value="S-1-1-0" />

Create the CA that will set the PROPERTY_TO_BE_TRANSLATED property and then call the CA doing the translation:

<CustomAction Id="TranslateAdmin_SetProperty" Property="PROPERTY_TO_BE_TRANSLATED" Value="AdminAccount"/>
<CustomAction Id="TranslateAdmin" BinaryKey="CommonCustomActions" DllEntry="TranslateSidToName" Impersonate="no" />
<CustomAction Id="TranslateEveryone_SetProperty" Property="PROPERTY_TO_BE_TRANSLATED" Value="EveryoneAccount" />
<CustomAction Id="TranslateEveryone" BinaryKey="CommonCustomActions" DllEntry="TranslateSidToName" Impersonate="no" />

Don't forget to use the msi properties when setting the permissions:

<CreateFolder>                
   <Permission GenericAll="yes" User="[AdminAccount]" />
   <Permission GenericRead="yes" GenericExecute="yes" User="[EveryoneAccount]" />
</CreateFolder>

Finally, schedule the CA before CreateFolder

 <InstallExecuteSequence>
   <Custom Action='TranslateAdmin_SetProperty' Before='TranslateAdmin' />
  <Custom Action='TranslateAdmin' Before='CreateFolders' />
  <Custom Action='TranslateEveryone_SetProperty' Before='TranslateEveryone' />
  <Custom Action='TranslateEveryone' Before='CreateFolders' />
  </InstallExecuteSequence>

In this way the CA is doing only some simple work, leaving the setting of permissions to the WiX element.

回答4:

As the <Permission> element clears the inheritance of permissions from parent folders, you could try using a single <Permission> element for users "Everyone" or "Administrators" followed by <util:PermissionEx> elements to set permissions for user names that are not supported by the <Permission> element, for example:

<Permission User="Everyone" GenericRead="no" />
<util:PermissionEx User="Users" Domain="[LOCAL_MACHINE_NAME]" GenericRead="yes" Read="yes" GenericExecute="yes" ChangePermission="yes" />

It is not needed to explicitly set permission for SYSTEM, as these are added automatically by the installer.

回答5:

you need to implement deferred custom action for changing permissions. c# custom action example:

[CustomAction]
public static ActionResult SetFolderPermission(Session session)
{
     string folder = session.CustomActionData["Folder"].Trim('\"');
     string sid = session.CustomActionData["SID"].Trim('\"');
     System.Security.Principal.SecurityIdentifier sidID =  new System.Security.Principal.SecurityIdentifier(sid);

     System.Security.AccessControl.DirectorySecurity ds = System.IO.Directory.GetAccessControl(folder);
     ds.AddAccessRule(new System.Security.AccessControl.FileSystemAccessRule(sidID 
                , System.Security.AccessControl.FileSystemRights.Write
                , System.Security.AccessControl.InheritanceFlags.ObjectInherit
                , System.Security.AccessControl.PropagationFlags.NoPropagateInherit
                , System.Security.AccessControl.AccessControlType.Allow));
     System.IO.Directory.SetAccessControl(folder , ds);

     return ActionResult.Success;
}

you may port that on C++, custom action must be deferred - than you must access your session properties by CustomActionData