[HelpOnLanguages] [TitleIndex] [WordIndex]

HilfeZuAccessControlLists

Access Control Lists

Schaltet man Access Control Lists (kurz ACLs, auf deutsch:Zugriffs-Kontroll-Listen) ein, kann man kontrollieren, wer was mit einer Wiki-Seite tun kann.

1. Inhalt

2. Grundlagen

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

#acl IrgendeinUser:read,write All:read

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

3. Syntax

Die Syntax jeder Zeile ist:

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

Hier bedeutet:

4. Mögliche Berechtigungen

Dies sind die möglichen Rechte, die in einer ACL vergeben werden können:

read
Den angegebenen Benutzern wird Leserecht für diese Seite erteilt.
write
Den angegebenen Benutzern wird Schreibrecht (und damit das Editieren) der Seite erlaubt.
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.

5. Verarbeitungslogik

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 Leser mit der Seite tun (oder nicht tun) darf.

(!) 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 die ACL-Syntax flexibler zu gestalten sind auch die Prefixe '+' und '-' möglich: Wenn sie benutzt werden, trifft der entsprechende ACL-Eintrag nur zu, wenn der Benutzer das entsprechende (erlaubte oder verweigerte) "Recht" anfordert. Zum Beispiel kann die o.g. ACL auch folgendermaßen geschrieben werden:

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

Oder auch:

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

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.

6. 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

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.

7. Konfiguration

Im Folgenden die Konfigurations-Möglichkeiten, um einer Moin-Site ACLs hinzuzufügen:

Eintrag

Default

Beschreibung

acl_enabled

0

Ermöglicht als TRUE-Wert die Benutzung von ACLs.

acl_rights_before

""

angewendet vor (before) Seiten- oder Default-ACLs

acl_rights_after

""

angewendet nach (after) Seiten- oder Default-ACLs

acl_rights_default

"Trusted:read,write,delete,revert Known:read,write,delete,revert All:read,write"

nur benutzt, wenn keine anderen ACLs für die angefragte Seite zutreffen

acl_rights_valid

["read", "write", "delete", "revert", "admin"]

Dies sind die akzeptierbaren (bekannten) Berechtigungen (und dies ist der Platz, sie zu erweitern, falls nötig).

Nun wissen Sie zwar, was es tut. Aber: was bedeutet es wirklich?

8. 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 (auf die config.page_group_regex zutrifft) 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.

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

page_group_regex =  '.*Group$'    # this is the default

9. Nutzungs-Beispiele

9.1. Eine öffentliche Community im Internet

ENGLISCH

The most important point here is to use ACLs only in cases where really needed. Wikis depend on openness of information and free editing. They use soft security to clean up bad stuff. So there is no general need for ACLs. If you use them too much, you might destroy the way wiki works.

This is why either ACLs should not be used at all (default) or, if used, the wikiconfig.py should look similar to that:

acl_rights_before = 'WikiEditorName:read,write,admin,delete,revert +AdminGroup:admin BadGuy:'

The default acl_rights_default option should be ok for you:

acl_default = 'Known:read,write,delete,revert All:read,write'

A good advice is to have only a few and very trusted admins in AdminGroup (they should be very aware of how a wiki works or they would maybe accidently destroy the way the wiki works: by its openness, not by being closed and locked!).

If using AdminGroup, you should make a page called AdminGroup and use it to define some people who get admin rights.

Specifing BadGuy like shown above basically locks him out - he can't read or edit anything with that account. That makes only sense if done temporarily, otherwise you also could just delete that account. Of course, this BadGuy can also work anonymously, so this is no real protection (this is where soft security will apply).

9.2. Wiki as a simple CMS

If you want to use a wiki to easily create web content, but if you don't want edits by the public (but only by some webmasters), you maybe want to use that in your wikiconfig.py:

acl_rights_default = 'All:read'
acl_rights_before  = 'WebMaster,OtherWebMaster:read,write,admin,delete,revert'

So everyone can read, but only the Webmasters can do anything else. As long as they still work on a new page, they can put

#acl All:

on it, so nobody else will be able to see the unready page. When being finished with it, don't forget to remove that line again, so that acl_rights_default will be used.

Some page(s) could also allow public comments (like one being called PublicComments), so you give more rights on that page:

#acl All:read,write

9.3. Wiki on Intranet

If you want to use a wiki on your intranet and you trust your users (not doing hostile stuff like locking others out or hijacking pages) to use the admin functionality in a senseful way, you maybe want to use that:

acl_rights_default = 'Known:admin,read,write,delete,revert All:read,write'
acl_rights_before  = 'WikiAdmin,BigBoss:read,write,admin,delete,revert'

So everyone can read, write and change ACL rights, WikiAdmin and BigBoss are enforced to be able to do anything, known users get admin rights by acl_rights_default (so they get it as long as no other ACL is in force for a page).

Consequences:

9.4. Wiki as a public company page

If you want to use a wiki as the company page, and don't want every user being able to change the company page content, you may want to use something like this:

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

This means that:

9.5. Comments on read-only page

You can easily add a comments section to a read-only page by using a writable subpage, and allowing users to write on it. For example, you can define SomePage like this:

#acl SomeUser:read,write All:read
'''Some read-only content'''

...

''' User comments '''
[[Include(SomePage/Comments)]]

And SomePage/Comments like this:

#acl All:read,write
Add your comments about SomePage here.

2014-08-13 10:44