2010-02-14 9 views
16

Ich habe alle verwandten Themen gelesen und habe keine vollständige Antwort auf mein Problem gefunden.WIX: Berechtigungen zu einem Ordner geben

Ich möchte volle Berechtigungen für SYSTEM geben und lesen & Ausführen von Berechtigungen für Benutzer Gruppe in einen Ordner unter Programme. Nicht mehr, nicht weniger.

Ich weiß, es gibt 3 Möglichkeiten, Berechtigungen für einen Ordner mit WIX zu geben, keiner von ihnen wirklich gut für mich und ich werde erklären, warum:

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: Es schlägt auf fremden OS fehl, da es das Schlüsselwort "Benutzer" nicht kennt. Ich habe es auch mit SID versucht. Außer, dass ich brauche das Permission Element unter jeder Datei im Testverzeichnis zu platzieren

2) (aber wenn dies der einzige Fall wäre, würde ich es geschafft haben) 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: Der Ordner behält auch die Standardberechtigungen des Ordners Programme bei. Das kann ich nicht zulassen.

3) PermissionEx mit Sddl:

Problem: Dieses Element ist nur verfügbar, wenn sie mit MSI 5.0 installieren. Ich benutze Installer 3.01.

Ich werde glücklich sein, eine Lösung zu erhalten, einschließlich Lösungen mit benutzerdefinierten Aktionen ...

Antwort

1

müssen Sie zum Ändern von Berechtigungen verzögerten Aktion implementieren. C# benutzerdefinierte Aktion Beispiel:

[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; 
} 

Sie können Port, der auf C++, benutzerdefinierte Aktion verschoben werden müssen - als Sie Ihre Sitzung Eigenschaften von Custom zugreifen müssen

2

Eine andere Möglichkeit wäre eine einfache CA zu haben, die einfach Übersetzen Sie eine MSI-Eigenschaft, die die SID enthält, auf den tatsächlichen Namen der Gruppe aus dem lokalisierten Betriebssystem. Die Zertifizierungsstelle muss nicht zurückgestellt werden, und sie erledigt nicht die eigentlichen Aufgaben zum Festlegen der Berechtigungen.

Unten ist ein Beispiel von CA, das den Wert der Eigenschaft PROPERTY_TO_BE_TRANSLATED msi liest und die von ihm angegebene msi-Eigenschaft übersetzt. Auf diese Weise können Sie die Zertifizierungsstelle ausführen, um verschiedene MSI-Eigenschaften zu übersetzen.

[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 definieren Sie die Eigenschaften übersetzt werden mit der SID for the accounts:

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

die CA erstellen, die die PROPERTY_TO_BE_TRANSLATED Eigenschaft festgelegt wird und dann die CA rufen Sie die Übersetzung zu tun:

<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" /> 

Vergessen Sie nicht, die MSI-Eigenschaften beim Festlegen der Berechtigungen zu verwenden:

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

Schließlich planen die CA vor Create

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

Auf diese Weise wird die CA nur einige einfache Arbeit tut, um die Einstellung von Berechtigungen für das WiX Element zu verlassen.

1

Als <Permission> Element die Vererbung von Berechtigungen von übergeordneten Ordner löscht, Sie könnten versuchen, eine einzelne <Permission> Element für Benutzer „Jeder“ oder „Administratoren“, gefolgt von < util mit: PermissionEx > Elemente Berechtigungen festlegen für Benutzername, die nicht unterstützt werden durch das <Permission> Element, zum Beispiel:

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

Es ist keine Berechtigung erforderlich, um für SYSTEM explizit festgelegt, da diese automatisch vom Installationsprogramm hinzugefügt werden.

6

Verwenden Sie den folgenden Code, um dies ohne benutzerdefinierte Aktion zu erreichen. Ich habe überprüft, dass dies funktioniert (auch in untergeordneten Ordnern). Auch die User Everyone ist auf lokalisierte Windows-Betriebssysteme abgebildet.

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

Dies funktioniert nicht für nicht-englische Locales, da "Jeder" lokalisiert werden muss. – John

+0

Ich habe keine Probleme gemeldet und wir setzen auf alle Kulturen. Wie hast du es behoben? –

6

Ich hatte genau dieses Problem und sprach mit Rob M darüber. Ich wollte Christian Gs Antwort (https://stackoverflow.com/a/5296967/18475) machen, aber Rob schlug vor, WixQueryOsWellKnownSID (http://wix.sourceforge.net/manual-wix3/osinfo.htm) zu verwenden, um nicht in den USA verfügbare Sprachumgebungen zu umgehen.

In der .wxs Datei hinzufügen, die Sie wie folgt vor:

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

Und weiter unten in der .wxs Datei, in der Sie die Berechtigungen anwenden möchten es so einfach ist:

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

Nun, wenn Sie laufen Licht, müssen Sie nur WixUtilExtension verknüpfen.

light -ext WiXUtilExtension ... 

HINWEIS: Je nach Ihrer Version von WiX, diese nicht vollständig unterstützt werden. Wenn es für Sie nicht funktioniert, gibt es möglicherweise andere Optionen, die Sie zu translate SIDs verwenden können.

+0

Seien Sie gewarnt, ich denke, wir mussten das aus irgendeinem Grund ausbügeln. – ferventcoder

+0

Das funktioniert nicht für mich.[WIX_ACCOUNT_USERS] wird in "BUILTIN \ Users" aufgelöst und erteilt einem Benutzer namens "BUILTIN" die Berechtigung. –

+0

Das oben erwähnte Verhalten ist nur wahr, wenn Sie die Berechtigungen in einem Mergemodul festlegen! Wenn Sie [WIX_ACCOUNT_USERS] in einem WiX-Projekt und nicht in einem WiX-Mergemodul verwenden, werden die Berechtigungen für die Benutzergruppe korrekt festgelegt. –

Verwandte Themen