Access Control Lists

Mit Access Control Lists (kurz: ACLs, auf deutsch:Zugriffs-Kontroll-Listen) kann man bestimmten Benutzern oder Benutzergruppen das Recht geben, bestimmte Aktionen auszuführen. Sie können benutzt werden, um:

• einige Seiten vor der Öffentlichkeit zu verstecken
• nur bestimmte Seiten der Öffentlichkeit zugänglich zu machen
• einer Person oder einer Gruppe Schreibzugriff auf eine oder mehrere Seiten zu geben
• das Löschen von Seiten zu erlauben oder zu verbieten
• zu bestimmen, wer Zugriffsregeln einer Seite ändern darf

Um ACLs zu benutzen brauchen Sie entweder Zugriff auf die Wiki-Config (um globale ACLs zu setzen) oder admin-Rechte auf der Seite, wo Sie ACLs setzen oder ändern wollen.

1. Inhalt

2. Grundlagen

Die verfügbaren ACL-Rechte sind:

• read - wer darf eine Seite lesen
• write - wer darf eine Seite editieren
• delete - wer darf eine Seite löschen
• revert - wer darf eine alte Revision einer Seite restaurieren
• admin - wer darf die "#acl"-Zeile auf einer Seite ändern

ACLs können in moin einfach durch Hinzufügen einer Steueranweisung am Anfang einer Seite realisiert werden:

#acl IrgendeinUser:read,write All:read

• Sie benötigen admin-Rechte, um eine solche ACL-Zeile hinzufügen oder ändern zu können - siehe HelpOnConfiguration und HelpOnAutoAdmin.

Das erlaubt IrgendeinUser, die Seite zu lesen und zu bearbeiten, während alle anderen Nutzer lediglich Lese-Rechte in der Seite haben (außer man hat einige Spezial-Konfigurationen in der Konfiguration gemacht).

Dateianhänge werden ebenfalls durch die ACLs der Seite kontrolliert, an die sie angehängt sind.

3. Konfiguration

Folgende Settings kann man benutzen, um ACLs zu konfigurieren:

Nun wissen Sie, was es macht - aber was bedeutet es?

• "before" bedeutet Rechte erzwingen - benutzen Sie das für globale Admins oder Editoren

• "default" bedeutet was wird getan, wenn keine ACLs auf der Seite angegeben wurden. Es ist gleichbedeutend wie wenn man genau diese ACLs auf eine Seite schreibt. Außerdem sind dies die Rechte, die einbezogen werden, wenn Default in einer ACL auf einer Seite angegeben wird.

• "after" bedeutet, etwas nicht aus Versehen zu vergessen (wie z.B. jedem Leserechte zu geben)

Es hilft, wennn Sie sich das einfach als "vor" (before), während, und "nach" (after) der Verarbeitung von seitenbasierten ACLs vorstellen.

Die u""-Notation, die für die Settings benutzt wird, bedeutet unicode und muss verwendet werden - siehe HelpOnConfiguration.

4. Syntax

Die Syntax jeder Zeile ist:

#acl [+-]User[,SomeGroup,...]:[right[,right,...]] [[+-]OtherUser:...] [[+-]Trusted:...] [[+-]Known:...] [[+-]All:...] [Default]

Hier bedeutet:

• User ist ein Benutzername und erteilt die zugehörige Berechtigung nur dann, wenn der Nutzername übereinstimmt.

• SomeGroup ist ein Seitenname, der auf page_group_regex passt, mit Zeilen der Form " * Member" (siehe #Gruppen).

• Trusted ist eine spezielle Gruppe, die alle authentifizierten Nutzer einer Trusted-Authentifizierungsmethode enthält.

• Known ist eine spezielle Gruppe, die alle angemeldeten Nutzer enthält.

• All ist eine allgemeine Gruppe, die alle Nutzer enthält, sowohl bekannte als auch anonyme.

• Default ist ein Eintrag, der in allen ACLs die Einträge von acl_rights_default ersetzt. (Siehe #Default).

• right ist eine "Berechtigung" der Art read, write, delete, revert, admin. Nur Wörter in acl_rights_valid werden akzeptiert, alle anderen werden ignoriert. Es ist durchaus zulässig, keine Rechte zu spezifizieren, was soviel bedeutet, dass keine Rechte gewährt werden.

5. Mögliche Berechtigungen

Dies sind die verfügbaren Rechte, die in einer ACL benutzt werden können. DeletePage und RenamePage sind nicht erlaubt, wenn der Benutzer nicht Known ist, selbst wenn ein delete-Recht gewährt wurde.

read

Den angegebenen Benutzern wird Leserecht für diese Seite erteilt und sie dürfen auch Dateianhänge lesen/herunterladen.

write

Den angegebenen Benutzern wird Schreibrecht (und damit das Editieren) der Seite erlaubt. Sie dürfen auch Dateianhänge hochladen.

delete

Die angegebenen Benutzer dürfen die Seite und ihre Anhänge löschen.

revert

Die angegebenen Benutzer dürfen eine ältere Version der Seite restaurieren.

admin

Die angegebenen Benutzer haben Adminrechte auf dieser Seite. Das bedeutet, dass sie selbst ACL-Einstellungen ändern dürfen - inklusive dem Recht, andere zu "Admins" zu machen oder ihnen das "Admin"-Recht zu entziehen.

Es gibt kein separates rename-Recht: eine Seite/Anhang umzubenennen setzt voraus, dass ein Benutzer "read"-, "write"- und "delete"-Rechte hat.

6. Verarbeitungslogik auf einer einzelnen Seite

Wenn ein Benutzer versucht, eine ACL-geschütze Seite abzurufen, werden die ACLs der Reihenfolge nach abgearbeitet. Die erste "passende" ACL sagt aus, was der Benutzer mit der Seite tun (oder nicht tun) darf und die Verarbeitung hält an, sobald ein zum Benutzer passender ACL-Eintrag gefunden wurde.

Aufgrund dieses first match-Algorithmus sollte man die ACLs sortieren: Zu Beginn einzelne Usernamen, dann spezielle Gruppen, anschließend algemeinere Gruppen und zum Schluss Known und All.

Beispielsweise sagt die folgende ACL aus, dass IrgendeinUser lesend und schreibend auf die ACL-geschützte Seite zugreifen darf, dass alle Mitglieder der Gruppe IrgendeineGruppe (ausser IrgendeinUser, falls er Mitglied der Gruppe ist) zusätzlich auch Admin-Rechte haben, während alle anderen User lediglich lesen dürfen.

#acl IrgendeinUser:read,write IrgendeineGruppe:read,write,admin All:read

Um das ACL-System flexibler zu gestalten, gibt es zwei Präfixe '+' und '-'. Wenn sie benutzt werden, hält die Verarbeitung nur dann an, wenn das angeforderte Recht für einen bestimmten Benutzer mit dem Benutzer und Recht in dem gegebenen ACL-Eintrag übereinstimmt, läuft aber weiter, wenn nach einem anderen Recht (oder anderen Benutzer) gesucht wird. Im Fall von '+' wird das Recht gewährt, im Fall von '-' wird das Recht verweigert.

Zum Beispiel kann die o.g. ACL auch folgendermaßen geschrieben werden, wenn EinUser Mitglied von EineGruppe ist:

#acl -EinUser:admin EineGruppe:read,write,admin All:read

Dieses Beispiel ist nur für EinUser besonders, denn wenn admin-Rechte für EinUser abgefragt werden, wird es verweigert werden und die Verarbeitung hält an. In allen anderen Fällen, geht die Verarbeitung weiter.

Oder auch:

#acl +All:read -EinUser:admin EineGruppe:read,write,admin

+All:read bedeutet, dass wenn irgendein Benutzer das read-Recht anfordert, es gewährt werden wird und die Verarbeitung anhält. In jedem anderen Fall, wird die Verarbeitung weiterlaufen. Wenn das admin-Recht für Benutzer EinUser abgefragt wird, wird es verweigert werden und die Verarbeitung hält an. In jedem anderen Fall, geht die Verarbeitung weiter. Letztendlich wird, wenn ein Mitglied der Gruppe EineGruppe ein Recht verlangt, es dann gewährt, wenn es hier angegeben ist und verweigert, wenn nicht. Alle anderen Benutzer haben keine Rechte, es sei denn, sie werden durch die Konfiguration gewährt.

Bitte beachten Sie, dass Sie das 2. und 3. Beispiel wohl kaum auf einer Wikiseite verwenden wollen. Derartige ACLs sind aber in den Konfigurationseinträgen des Wikis sinnvoll.

7. Erben von Default-Einstellungen

Manchmal ist es nützlich, jemandem Rechte zu vergeben, ohne die Default-Berechtigungen zu beeinflussen. Nehmen wir als Beispiel an, Sie hätten folgende Einträge in ihrer Konfiguration:

acl_rights_default = "TrustedGroup:read,write,delete,revert All:read"
acl_rights_before  = "AdminGroup:admin,read,write,delete,revert +TrustedGroup:admin"

Sie möchten einige Seiten zum Schreiben für EinUser freigeben, aber gleichzeitig das Default-Verhalten bezüglich All und der TrustedGroup beibehalten. Sie können einfach den Default-Eintrag nutzen:

#acl EinUser:read,write Default

Das fügt die Einträge von acl_rights_default exakt an der Stelle ein, wo der "Default"-Ausdruck steht. Sie haben also das gleiche geschrieben wie:

#acl EinUser:read,write TrustedGroup:read,write,delete,revert All:read

Nun schauen wir mal das erste Beispiel dieses Abschnitts genauer an: acl_rights_before = "AdminGroup:admin,read,write,delete,revert +TrustedGroup:admin"

ACLs werden in der Reihenfolge "before", dann "Seiten-ACLs/default" und dann "after" verarbeitet, von "links nach rechts".

Es fängt also links in "before" an mit AdminGroup:... - dies trifft zu, wenn der Benutzer ein Mitglied der AdminGroup ist. Wenn es zutrifft, erhält der Benutzer diese Rechte (arwdr) und die ACL-Verarbeitung hält an.

Wenn es nicht zutrifft, geht die ACL-Verarbeitung weiter mit +TrustedGroup:admin - dies trifft zu, wenn der Benutzer Mitglied der TrustedGroup ist.

Wenn es zutrifft, bekommt der Benutzer die Rechte (a) und - jetzt kommt der Unterschied wegen dem Plus-Präfix - die ACL-Verarbeitung geht weiter! Wenn es also weitere zutreffende Einträge gibt für diesen Benutzer oder seine Gruppe oder Known: oder All:, wird der Benutzer auch diese Rechte erhalten.

Wenn es nicht zutrifft, geht die ACL-Verarbeitung weiter - mit den Seiten-ACLs (wenn es ACLs auf der Seite gibt) oder mit den default-ACLs (wenn es keine ACLs auf der Seite gibt) und zuletzt dann mit den "after"-ACLs.

Weil dies genau das gleiche ausdrückt, hat das Erben von Default-Einstellungen den Vorteil, dass alle Änderungen an Default-Einstellungen automatisch in alle ACLs übernommen werden, die mit der Default-Einstellung arbeiten.

8. Hierarchische ACL-Verarbeitung

Neu in Version 1.6

Wenn Sie acl_hierarchic aktivieren (siehe oben), dann werden die Wikiseiten als Hierarchie verstanden und Berechtigungen, die auf übergeordneten Seiten gesetzt werden, können die Zugriffsrechte des Benutzers beeinflussen.

Kurz gesagt: wenn eine Berechtigung nicht durch die aktuelle Seite definiert ist, werden die ACLs der Elternseite geprüft, dann davon die Eltern, usw. bi es keine Elternseite mehr gibt.

Alle normalen ACL-Regeln werden beachtet, wie oben beschrieben, aber anstatt nur die ACL der aktuellen Seite zu prüfen, wird an die #acl-Zeile der Seite alle #acl-Zeilen aller übergeordneten Seiten in der Hierarchie angehängt, bis zur obersten Seite. Betrachten Sie folgendes Beispiel einer Seite namens A/B/C/D, das die Verarbeitung mit und ohne hierarchische ACLs gegenüberstellt:

Beachten Sie, dass acl_rights_before, acl_rights_default, und acl_rights_after nicht einmal pro Seite in der Hierarchie angewendet werden, sondern nur einmal insgesamt. Für die default-ACL bedeutet das, dass sie immer noch wie zuvor funktioniert, sie wird aber nicht angewandt, wenn die aktuelle Seite keine ACLs definiert, sondern nur wenn gar keine der Seiten in der Hierarchie eine ACL definieren. Im Endeffekt tun also hierarchische ACLs nichts anderes, als die ACL der aktuellen Seite durch eine Aneinanderreihung aller #acl-Zeilen, die in der Hierarchie dieser Seite gefunden werden, zu ersetzen.

9. Gruppen

Benutzergruppen erleichtern es, Rechte für Gruppen von Personen zu spezifizieren.

Nur die Freunde von EinUser dürfen diese Seite lesen und editieren:

#acl EinUser:read,write EinUser/FreundesGruppe:read,write

EinUser/FreundesGruppe ist eine Seite, auf der jeder Listen-Eintrag einem Wiki-Usernamen entspricht, der zu genau dieser Gruppe gehören soll:

#acl EinUser:read,write,admin,delete,revert
 * JoeSmith
 * JoeDoe
 * JoeMiller

Eine Seite AdminGroup könnte eine gleichnamige Gruppe definieren und ebenfalls durch ACLs geschützt werden:

#acl AdminGroup:admin,read,write All:read
 * EinUser
 * EinWeitererUser
   * Dies wird momentan ignoriert.
Auch jeder weitere Text, der nicht in der Liste der ersten Ebene steht, wird ignoriert.

Eine Liste der ersten Ebene ist eine mit nur einem Leerzeichen vor dem Stern (und es muss auch ein Leerzeichen hinter dem Stern sein). Folgendes wird nicht funktionieren:

  * ein benutzer
-- zwei Leerzeichen, deshalb funktioniert dies nicht

Man kann konfigurieren, welche Seitennamen als Gruppenseiten betrachtet werden (z.B. für nicht-englische Wikis):

page_group_regex = ur'(?P<all>(?P<key>\S+)Group)'    # dies ist der Default-Wert (nur Englisch)

Wenn Änderungen an einer Gruppenseite sich nicht auswirken, sollte man MoinMoin den Cache neu aufbauen lassen, indem man einfach alle Dateien im Verzeichnis path_to_your_wiki_instance/data/cache/wikidicts/ löscht.

Bitte beachten Sie, dass Sie nach dem Anlegen einiger Gruppenseiten dann diese Gruppen auch in ACLs auf Ihren Wiki-Seiten oder in Ihrer Wiki-Konfiguration verwenden möchten (oder dass sonst sich nichts ändern wird - moin hat keine vordefinierten Gruppen bzw. keine vordefinierten ACLs für bestimmte Gruppen).

10. Nutzungs-Beispiele

Siehen unten auf HelpOnAccessControlLists.

MoinMoin Release 1.9.11 [Revision release], Copyright by Juergen Hermann et al.