Zugriffskontroll-Listen (Access Control Lists, ACLs) im DTR 

Eine Zugriffskontroll-Liste (Access Control List, ACL) definiert, welche Principals (das kann ein Benutzer oder eine Benutzergruppe sein) welche Privilegien für eine bestimmte Ressource haben. Technisch besteht eine ACL aus Zugriffskontroll-Einträgen (Access Control Entities, ACE). Diese ordnet ihrerseits einem Principal ein oder mehrere Privilegien zu.

In der folgenden Grafik sehen Sie das Klassen-Diagramm der Zugriffs-Liste (ACL):

 

Klassen-Diagramm der Zugriffskontroll-Liste (ACL)

Regeln

Es ist nicht nötig, ACLs für alle Ressourcen definieren. Andererseits ist es möglich, einander ausschließende ACEs für dieselbe Ressource zu definieren. Zur Lösung dieser Konflikte werden die Berechtigungen nach einem Satz bestimmter Regeln interpretiert, die für alle Privilegien unabhängig voneinander angewandt werden.

Zur Bestimmung der Berechtigungen wird der Ressourcenpfad verwendet. Die Berechtigungen müssen nicht für alle Ressourcen definiert werden: Eine Ressource untergeordneter Hierarchiestufe erbt alle Berechtigungen, die auf einem übergeordneten Ordner vergeben wurden, falls ihr nicht direkt Berechtigungen zugeordnet wurden.

Regel 1 – „final“ vor allen „children“

Eine mit final versehene ACL setzt alle anderen ACLs außer Kraft, die für untergeordnete Ressourcen definiert wurden.

Das Attribut „final“ erlaubt einem Systemadministrator, Bereiche des DTR vorübergehend in einen „read-only“-Zustand zu versetzen, ohne die bestehenden Berechtigungen löschen zu müssen.

Normalerweise gelten folgende Berechtigungen:

Ressource	Inheritance	Principal	Privileges
/		administrators	grant adminX
/projects		developers	grant read
/projects/java/dev		developers	grant write

 

Nun wollen Sie zur Durchführung einer administrativen Aufgabe alle Mitglieder der Gruppe developers daran hindern, Änderungen ins DTR einzuchecken. Hierzu ist ein mit final verwehrtes write-Privileg auf „/“ erforderlich. Zusätzlich muss die Zugriffsliste als final deklariert sein:

Ressource	Inheritance	Principal	Privileges
/		developers	deny write

 

Regel 2 – „ignore inheritance“

Diese Regel erlaubt es, die Vererbungshierachie zu mit dem Attribut „ignore inheritance“ unterbrechen. Eine Resource für die eine mit ignore inheritance versehene ACL definiert wurde, erbt keine Berechtigungen von übergeordneten Ordnern.

Es gibt zwei Projektgruppen, deren Mitglieder in den Gruppen DevelopersA bzw. DevelopersB sind. Alle Projektmitglieder sind auch Mitglied in der Gruppe Developers. Auf der Verzeichnisstruktur /projects/A/java/dev/project-internal sind folgende Berechtigungen vergeben:

Ressource	Inheritance	Principal	Privileges
/projects		Developers	grant read
/projects/B/java/dev		DevelopersB	grant write
/projects/A/java/dev		DevelopersA	grant write
/projects/A/java/dev/project-internal	ignore inheritance	DevelopersA	grant read grant write

·         Alle Mitglieder der Gruppe Developers können alles unterhalb des Verzeichnisses /projects lesen, mit Ausnahme des Verzeichnisses /projects/A/java/dev/project-internal: Dieses Verzeichnis kann nur von Mitgliedern der Gruppe DevelopersA gelesen werden.

·         Alle Mitglieder der Gruppe DevelopersA haben Lese- und Schreibberechtigung für alle Ressources unterhalb des Verzeichnisses /projects/A/java/dev.

·         Alle Mitglieder der Gruppe DevelopersB haben Lese- und Schreibberechtigung für alle Ressources unterhalb des Verzeichnisses /projects/B/java/dev.

Regel 1 hat Vorrang vor Regel 2 hat. Das bedeutet, dass wenn auf einer übergeordneten Ressource eine final ACL definiert wurde, dann werden alle ACLs auf untergeordneten Ressourcen ignoriert, auch wenn sie mit ignore inheritance definiert wurden.

Regel 3 – „child” vor „parent“

Diese Regel erlaubt die Verfeinerung von Berechtigungen auf untergeordneten Ressourcen.

Auf der Verzeichnisstruktur /projects/java/dev/.../secret/.../confidential sind folgende Berechtigungen vergeben:

Ressource	Principal	Privileges
/projects	Developers	grant read
/projects/java/dev	Developers	grant write
/projects/java/dev/.../secret	Developers	deny read deny write
/projects/java/dev/.../secret/.../confidential	User07	grant read grant write

·         Alle Mitglieder der Gruppe Developers kann alles unterhalb des Verzeichnisses /projects lesen, mit Ausnahme des Verzeichnisses secret.

·         Alle Mitglieder der Gruppe Developers haben Schreibberechtigung für alle Ressources unterhalb des Verzeichnisses dev, außer für den Teilbaum unterhalb von secret.

·         Nur der Benutzer User07 kann auf den Teilbaum unterhalb von confidential (lesend und schreibend) zugreifen. Aber auch dieser Benutzer kann nicht auf die Ressourcen zwischen secret und confidential zugreifen (wenn sie oder er Mitglieder der Gruppe Developers sind).

Regel 4 – „user” vor „group“

Diese Regel definiert den Vorrang bei widersprüchlichen ACEs, die für dieselbe Ressource definiert sind (da diese Regel nach Regel 3 angewendet wird, kann sie sich nur auf dieselbe Ressource auswirken). Sie bevorzugt den Eintrag zum Benutzer vor dem zur Gruppe.

 

·         Benutzer X gehört zur Gruppe A.  

·         Gruppe A hat die Deny -Schreib-Berechtigung für die Ressource /ws/wsdir/myws/com/tssap.

·         Benutzer X  hat Grant -Schreib-Berechtigung für die selbe Ressource.

In diesem Fall wird dem Benutzer X das Schreiben in dieser Ressource erlaubt, obwohl den Mitgliedern der Gruppe A dieses Recht verwehrt wird.

Regel 5 – „deny” vor „grant“

Gibt es für ein Privileg sowohl eine grant- als auch eine deny-Berechtigung, so hat die deny-Berechtigung Vorrang. Da diese Regel nach Regel 4 angewendet wird, kann sie sich nur auf kollidierende Berechtigungen für denselben Benutzer auswirken oder für Benutzergruppen, die ein gemeinsames Mitglied haben.

·         Benutzer X gehört zur Gruppe A und zur Gruppe B.

·         Gruppe A hat die grant-Schreib-Berechtigung für die Ressource /ws/wsdir/myws/.

·         Gruppe B hat die deny-Schreib-Berechtigung für dieselbe Ressource.

In diesem Fall wird Benutzer X das Schreiben in dieser Ressource verweigert. Es gilt jedoch immer noch Regel 3 (Benutzer vor Gruppe).