Allgemein Für Administratoren Für Architekten Für Entwickler Für Projektleiter Für Tester News Produkte Publikationen
X
Eike Brändle

Eike Brändle

WiX Toolset Teil 5: Access denied! – Permissions setzen leicht gemacht

Dienstag, 19. Juli 2016

Herzlich willkommen zum fünften Teil der WiX-Blog-Serie. Jeder, der im Alltag mit Computern arbeitet, kommt irgendwann an einen Punkt, an dem Administratoren-Rechte auf dem System sehr hilfreich wären, um ein Problem schnell und unkompliziert zu lösen. Aus Sicht des IT-Supports wäre das gleichzusetzen mit absoluter Anarchie. Jeder macht was er will, keiner macht was er soll, aber alle machen mit. Beschränkungen stellen in der Regel sicher, dass nur diejenigen, die ganz genau wissen, was sie tun, tiefere Eingriffe in ein bestehendes System durchführen können. Dies gewährleistet einen konsistenten Zustand des Gesamt-Systems.

Trotzdem müssen auch Anwendern in bestimmten Bereichen weitreichende Rechte eingeräumt werden. Eine installierte Anwendung, die vom angemeldeten Nutzer zwar gesehen, aber nicht ausgeführt werden darf, kann auch nicht die Arbeitsleistung verbessern. Eine Anwendung, die eine Datei-basierte Datenbank benutzt, auf welcher der Anwender aber keine Schreib-Rechte hat, wird keine Daten persistieren können. Berechtigungen müssen also schon vor der ersten Ausführung einer Anwendung gesetzt werden. Am besten schon während der Installation. Dazu sind während der Installation zwar temporäre Administrations-Rechte nötig, diese werden bei vielen Firmen im Verteilungskonzept einer Software aber berücksichtigt. Wie sieht die Rechte-Vergabe mit Hilfe von WiX also aus?

Um das zu beantworten muss unterschieden werden zwischen drei zur Verfügung stehenden Elementen. Die Elemente Permission, PermissionEx und util:PermissionEx haben alle das gleiche Ziel: Berechtigungen setzen. Sie verfolgen jedoch verschiedene Wege um ans Ziel zu kommen.

Das Element PermissionEx ist ein mit WiX mitgeliefertes Element zum Schreiben von Berechtigungen. Es besitzt zwei Attribute: eine ID und einen SDDL-String (Security Descriptor Definition Language). Dieses Element ist nur für Installationsprojekte, die auf MSI 5.0 aufbauen verfügbar. Über den SDDL-String werden die genauen Berechtigungen des übergeordneten Elementes bestimmt. Denn eines haben alle Permission Elemente geminsam: Sie müssen stets einem anderen Element zugeordnet werden. Dies kann ein CreateFolder, ein File oder ein RegistryKey/Value Element sein. Somit werden die Berechtigungen auf einem Element gesetzt, das einem Component, und damit einem DirectoryRef-Element zugeordnet ist. Die Arbeit mit SDDL-Strings ist jedoch etwas gewöhnungsbedürftig und benötigt Einarbeitung, daher ist das PermissionEx-Element nicht für den Einstieg geeignet und soll hier nicht weiter betrachtet werden. Mehr Informationen über die Handhabung der SDDL-Strings findet man bei MSDN oder in verschiedenen Tutorials.

Das ebenfalls im Standard-WiX-Paket enthaltene Permission-Element kann mehrere Attribute beinhalten. Hier werden einzelne Berechtigungen über einzelne Attribute erteilt oder verweigert. Anders als das PermissionEx-Element, muss auch der User und die Domain des Users über ein Attribut definiert werden. Hierbei wird deutlich, dass ein Element auch mehrere Permission, beziehungsweise PermissionEx Elemente beinhalten kann, um unterschiedlichen Benutzern verschiedene Rechte-Sets zuzuweisen. Hierbei ist jedoch zu beachten, dass durch das Permission-Element, alle ACLs (Access Control List) überschrieben werden und somit nur noch die definierten Rechte-Sets gelten. Dies birgt bei unbedachtem Einsatz die Gefahr, sich selbst auszusperren. Im folgenden Beispiel gelten nach der Installation ausschließlich die definierten Rechte-Sets:

18-07-2016 15-54-24

Das letzte Element, das util:PermissionEx Element, ist kein Bestandteil des eigentlichen WiX-Pakets. Es ist in der Util-Extension enthalten und kann durch xmlns:util=“http://schemas.microsoft.com/wix/UtilExtension“ in den Installer eingebunden werden. Im Großen und Ganzen ähnelt das util:PermissionEx-Element dem mitgelieferten Permission-Element des WiX-Pakets. Der größte Unterschied ist jedoch, dass durch das util:PermissionEx-Element die ACLs nicht überschrieben, sondern modifiziert werden. Somit bleiben bestehende Berechtigungen, wie etwa der volle Zugriff für Administratoren, unberührt. Ein weiterer Vorteil des util:PermissionEx Elementes ist, dass ohne weiteres Zutun alle Unterordner die gleichen Berechtigungen wie der definierte Ordner erhalten.

Im Falle von Permission und util:PermissionEx werden Permissions einzeln als Attribut vergeben. Das Attribut Read setzt beispielsweise die Lese-Rechte des angegebenen Nutzers. Darüber hinaus existieren noch allgemeinere Rechte-Sammlungen. Neben GenericAll, was alle Rechte beinhaltet, gibt es noch GenericRead oder GenericWrite. Diese beinhalten verschiedene Rechte, die zum Lesen beziehungsweise Schreiben benötigt werden. Diese können nicht einzeln verboten werden, da sie implizit auch das Recht Synchronize beinhalten. Somit würde eine Anfrage für GenericRead fehlschlagen wenn GenericWrite verboten ist. Es wird daher empfohlen, explizit nur mit dem Erlauben von Rechten zu arbeiten, um solche impliziten Verkettungen auszuschließen.

Ein weiteres Pflicht-Attribut ist der User. Damit wird der Nutzer, für den die Berechtigung gesetzt werden soll, bestimmt. Dabei sind bestimmte Schlüsselwörter bereits vorhanden. Everyone, Administrators und Users werden auf jedem System erkannt. Darüber hinaus können weitere Benutzer beziehungsweise Gruppen angegeben werden. Dazu kann über das Domain-Attribut auch die entsprechende Domain  angegeben werden. Dies führt jedoch dazu, dass Installer an ein bestimmtes System angepasst werden müssen. Für interne Software einer Firma ist dies irrelevant, da nur das eigene System unterstützt werden muss. Falls das Zielsystem aber unbekannt ist, sollten nur die obigen allgemein erkannten Schlüsselwörter genutzt werden. Wesentlich einfacher kann dabei die Verwendung von Properties sein, die in Custom Actions mit den entsprechenden Werten gefüllt werden. Im folgenden Beispiel bleiben die bestehenden Rechte des Systems erhalten und werden entsprechend angepasst:

18-07-2016 15-50-29

Ausblick

Zu guter Letzt besteht natürlich immer die Möglichkeit, spezielle Wünsche über Custom Actions umzusetzen. Mit den Custom Actions sind dem Entwickler kaum noch Grenzen gesetzt, welche Vorgänge und Anpassungen während einer Installation durchgeführt werden sollen. Wie das aussieht, wird im nächsten Teil der WiX-Blog-Serie beleuchtet.

Verwandte Artikel:

Benötigen Sie Unterstützung bei der Software-Entwicklung und Architektur von .NET basierten Lösungen oder bei Einführung und Anpassung von Visual Studio / Microsoft Test Manager / Team Foundation Server?

Wir stehen Ihnen unter info(at)aitgmbh.de gerne zur Verfügung.

Tags: , , , ,

Hinterlasse eine Antwort