Diese Dokumentation wurde zur Beschreibung der Serie 1.6.x von Subversion erstellt. Falls Sie eine unterschiedliche Version von Subversion einsetzen, sei Ihnen dringend angeraten, bei http://www.svnbook.com/ vorbeizuschauen und stattdessen die zu Ihrer Version von Subversion passende Version dieser Dokumentation heranzzuiehen.

Pfadbasierte Autorisierung

Sowohl Apache als auch svnserve können Anwendern Zugriffsechte gewähren (oder verweigern). Normalerweise geschieht das für das gesamte Projektarchiv: ein Anwender darf das Projektarchiv lesen (oder auch nicht) und ein Anwender darf in das Projektarchiv schreiben (oder auch nicht). Es ist jedoch ebenfalls möglich, feiner abgestufte Zugriffsregeln zu definieren. Ein Anwender dürfte nur in ein bestimmtes Verzeichnis des Projektarchivs schreiben, aber in kein anderes; ein weiteres Verzeichnis könnte bis auf wenige besondere Personen für niemanden lesbar sein. Da es sich auch bei Dateien um Pfade handelt, ist es sogar möglich, den Zugriff dateiabhängig einzurichten.

Beide Server verwenden ein gemeinsames Dateiformat, um diese pfadbasierten Zugriffsregeln zu beschreiben. Im Falle von Apache muss das Modul mod_authz_svn geladen und dann die Direktive AuthzSVNAccessFile (in der Datei httpd.conf) hinzugefügt werden, die auf Ihre eigene Zugriffsregeldatei verweist. (Eine vollständige Erklärung finden Sie unter „Verzeichnisweise Zugangskontrolle“.) Falls Sie svnserve verwenden, müssen Sie dafür sorgen, dass die Variable authz-db (in svnserve.conf) auf Ihre Zugriffsregeldatei zeigt.

Sobald Ihr Server weiß, wo sich Ihre Regeldateien befinden, ist es an der Zeit, die Regeln zu definieren.

Die Syntax der Datei ist dieselbe wie bei svnserve.conf und den Laufzeit-Konfigurationsdateien. Zeilen, die mit einer Raute (#) beginnen, werden ignoriert. In der einfachsten Form benennt jeder Abschnitt ein Projektarchiv und einen Pfad darin. Die authentifizierten Anwendernamen sind die Optionen und der entsprechende Wert beschreibt das Zugriffsrecht des Anwenders auf den Pfad im Projektarchiv, entweder r (nur lesend) oder rw (lesend und schreibend). Wird der Anwender gar nicht erwähnt, ist kein Zugriff erlaubt.

Genauer gesagt: Der Wert des Abschnittnamens hat entweder das Format [projektarchiv-name:pfad] oder [pfad].

[Warnung] Warnung

Für Zwecke der Zugriffskontrolle beachtet Subversion bei Namen und Pfaden von Projektarchiven nicht die Groß- oder Kleinschreibung, indem sie vor dem Vergleich mit dem Inhalt der Zugriffsdatei in Kleinbuchstaben umgewandelt werden. Verwenden Sie Kleinbuchstaben für die Inhalte der Abschnittsüberschriften Ihrer Zugriffsdatei.

Falls Sie die Direktive SVNParentPath verwenden, ist es wichtig, die Namen der Projektarchive in den Abschnitten anzugeben. Falls Sie sie weglassen, wird ein Abschnitt wie etwa [/some/dir] auf den Pfad /some/dir jedes Projektarchivs zutreffen. Falls Sie jedoch die Direktive SVNPath verwenden, ist es in Ordnung, in den Abschnitten nur Pfade zu definieren, da es ja schließlich nur ein einziges Projektarchiv gibt.

[calc:/branches/calc/bug-142]
harry = rw
sally = r

Im ersten Beispiel hat der Anwender harry vollständigen Lese- und Schreibzugriff auf das Verzeichnis /branches/calc/bug-142 im Projektarchiv calc, die Anwenderin sally hat jedoch nur Lesezugriff. Allen anderen Anwendern ist der Zugriff auf dieses Verzeichnis nicht gestattet.

[Warnung] Warnung

mod_dav_svn bietet eine Direktive SVNReposName an, die es Administratoren ermöglicht, einen etwas menschenlesbareren Namen für ein Projektarchiv festzulegen:

<Location /svn/calc>
  SVNPath /var/svn/calc
  SVNReposName "Calculator Application"
…

Das gestattet mod_dav_svn, das Projektarchiv durch etwas anderes als den Basisnamen des Serververzeichnisses, im vorangegangenen Beispiel calc, zu identifizieren, wenn Verzeichnislisten zum Inhalt des Projektarchivs ausgegeben werden. Denken Sie jedoch daran, dass beim Suchen von Autorisierungsregeln in der Zugriffsdatei Subversion diesen Projektarchiv-Basisnamen verwendet und nicht irgendeinen konfigurierten menschenlesbaren Namen.

Selbstverständlich werden Berechtigungen von den Eltern- auf die Kindverzeichnisse vererbt. Das bedeutet, dass wir ein Unterverzeichnis mit unterschiedlichen Berechtigungen für Sally angeben können:

[calc:/branches/calc/bug-142]
harry = rw
sally = r

# Sally bekommt nur für das Unterverzeichnis 'testing' Schreibrecht
[calc:/branches/calc/bug-142/testing]
sally = rw

Nun kann Sally im Verzeichnis testing des Zweigs zwar schreiben, an anderen Stellen allerdings immer noch nur lesen. Andererseits besitzt Harry weiterhin vollständigen Lese- und Schreibzugriff auf den gesamten Zweig.

Es ist ebenfalls möglich, einer Person über die Vererbungsregeln explizit Berechtigungen zu entziehen, indem die Variable mit dem Anwendernamen auf den leeren Wert gesetzt wird:

[calc:/branches/calc/bug-142]
harry = rw
sally = r

[calc:/branches/calc/bug-142/secret]
harry =

In diesem Beispiel hat Harry Lese- und Schreibzugriff auf den gesamten Baum bug-142, jedoch überhaupt keinen Zugriff auf das darin befindliche Unterverzeichnis secret.

[Tipp] Tipp

Man muss sich nur merken, dass der am genauesten angegebene Pfad stets am besten passt. Der Server versucht zunächst, den Pfad selbst abzugleichen, dann das Elternverzeichnis hiervon, dann dessen Elternverzeichnis usw. Unter dem Strich läuft es darauf hinaus, dass die Erwähnung eines bestimmten Pfades in der Zugriffsdatei stets die von Elternverzeichnissen ererbten Berechtigungen überdeckt.

Standardmäßig hat niemand irgendeine Zugriffsberechtigung auf das Projektarchiv. Das bedeutet, wenn mit einer leeren Datei begonnen wird, sollte mindestens für alle Anwender die Leseberechtigung für die Wurzel des Projektarchivs gewährt werden. Das kann mit der Stern-Variablen (*) erreicht werden, die für alle Anwender steht:

[/]
* = r

Dies ist eine verbreitete Einstellung. Beachten Sie, dass im Abschnittsnamen kein Projektarchiv erwähnt wird. Das führt dazu, dass alle Projektarchive für alle Anwender der Welt lesbar sind. Sobald alle Anwender Lesezugriff auf die Projektarchive haben, können Sie bestimmten Anwendern für ausgewählte Verzeichnisse bestimmter Projektarchive die Berechtigung rw geben.

Die Zugriffsdatei erlaubt es Ihnen auch, ganze Anwendergruppen zu definieren, ähnlich der Unix-Datei /etc/group:

[groups]
calc-developers = harry, sally, joe
paint-developers = frank, sally, jane
everyone = harry, sally, joe, frank, jane

Gruppen können ebenso wie Anwendern Zugriffsberechtigungen erteilt werden. Sie werden von Anwendern durch einen At-Präfix (@) unterschieden:

[calc:/projects/calc]
@calc-developers = rw

[paint:/projects/paint]
jane = r
@paint-developers = rw

Ein weiterer wichtiger Punkt ist, dass Gruppenberechtigungen nicht durch die Berechtigungen individueller Anwender überschrieben werden. Vielmehr wird die Kombination aller passender Berechtigungen zugesichert. Im vorangehenden Beispiel ist Jane Mitglied der Gruppe paint-developers, die über Lese- und Schreibzugriff verfügt. Kombiniert mit der Regel jane = r ergibt das immer noch Lese- und Schreibzugriff für Jane. Zugriffsrechte für Gruppenmitglieder können allenfalls über die Gruppenberechtigungen hinaus erweitert werden. Die Einschränkung von Anwendern, die Gruppenmitglieder sind auf geringere Berechtigungen als deren Gruppenberechtigung ist nicht möglich.

Gruppen können auch definiert werden, indem sie andere Gruppen beinhalten:

[groups]
calc-developers = harry, sally, joe
paint-developers = frank, sally, jane
everyone = @calc-developers, @paint-developers

Subversion 1.5 brachte einige nützliche Erweiterungen für die Syntax der Zugriffsdatei: Anwendernamen-Aliase, Authentifizierungsklassen-Symbol und einen neuen Regel-Ausschlussmechanismus. Dieses alles vereinfacht die Wartung der Zugriffsdatei. Zunächst beschreiben wir die Funktionalität des Anwendernamen-Alias.

Einige Authentifikationssysteme erwarten und verwenden relativ kurze Anwendernamen, wie wir sie hier bereits beschrieben haben: harry, sally, joe usw. Andere Authentifikationssysteme jedoch, wie solche, die LDAP oder SSL-Client-Zertifikate verwenden, könnten wesentlich komplexere Anwendernamen verwenden. So könnte beispielsweise Harrys Anwendername in einem durch LDAP geschützten System CN=Harold Hacker,OU=Engineers,DC=red-bean,DC=com lauten. Mit derartigen Anwendernamen könnte die Zugriffsdatei mit langen oder undurchsichtigen Anwendernamen zugemüllt werden, was auch leicht zu Tippfehlern führen kann. Glücklicherweise ermöglichen es Anwendernamen-Aliase, den komplizierten Anwendernamen nur einmal in einer Anweisung einzutippen, die ihm ein einfacheres Alias zuteilt.

[aliases]
harry = CN=Harold Hacker,OU=Engineers,DC=red-bean,DC=com
sally = CN=Sally Swatterbug,OU=Engineers,DC=red-bean,DC=com
joe = CN=Gerald I. Joseph,OU=Engineers,DC=red-bean,DC=com
…

Sobald Sie eine Menge an Aliasen definiert haben, können Sie sich an allen Stellen der Zugriffsdatei über die Aliase auf die Anwender beziehen, an denen Sie sonst die eigentlichen Anwendernamen benutzt hätten. Setzen Sie einfach ein kaufmännisches Und vor den Alias, um ihn von einem normalen Anwendernamen zu unterscheiden:

[groups]
calc-developers = &harry, &sally, &joe
paint-developers = &frank, &sally, &jane
everyone = @calc-developers, @paint-developers

Sie könnten sich auch dazu entscheiden, Aliase zu verwenden, falls sich die Anwendernamen Ihrer Anwender häufig ändern. In diesem Fall müssen Sie bei Änderungen der Anwendernamen lediglich die Aliastabelle aktualisieren anstatt eine globale Such- und Ersetzungsoperation über die gesamte Zugriffsdatei vornehmen zu müssen.

Ferner unterstützt Subversion einige magische Symbole, die Ihnen dabei helfen sollen, Regeln abhängig von der Authentifizierungsklasse des Anwenders zu vergeben. Ein solches Symbol ist $authenticated. Verwenden Sie dieses Symbol dort, wo Sie ansonsten einen Anwendernamen, einen Alias oder einen Gruppennamen in Ihren Autorisierungsregeln angeben würden, um die Zugriffsrechte zu deklarieren, die ein Anwender erteilt bekommt, der sich schon einmal mit einem Anwendernamen anmeldet. Ähnlich wird das Symbol $anonymous verwendet, mit der Ausnahme, dass es auf jeden anwendbar ist, der sich nicht mit einem Anwendernamen authentifiziert hat.

[calendar:/projects/calendar]
$anonymous = r
$authenticated = rw

Ein weiteres praktisches Stück magischer Zugriffsdatei-Syntax ist die Verwendung der Tilde (~) als eine Ausschlussmarkierung. Wenn Sie in Ihren Autorisierungsregeln einem Anwendernamen, einem Alias, einen Gruppennamen oder einem Authentifizierungsklassen-Symbol eine Tilde voranstellen, gilt diese Regel für Anwender, die nicht durch diese Regel erfasst werden. Obwohl es unnötigerweise etwas verwirrend erscheint, ist der folgende Block äquivalent zu dem aus dem vorangegangenen Beispiel:

[calendar:/projects/calendar]
~$authenticated = r
~$anonymous = rw

Ein weniger offensichtliches Beispiel könnte wie folgt aussehen:

[groups]
calc-developers = &harry, &sally, &joe
calc-owners = &hewlett, &packard
calc = @calc-developers, @calc-owners

# jeder calc-Teilnehmer hat Lese- und Schreibzugriff...
[calc:/projects/calc]
@calc = rw

# ...doch nur die Eigentümer dürfen Release-Tags erstellen und ändern.
[calc:/projects/calc/tags]
~@calc-owners = r

Alle obigen Beispiele verwenden Verzeichnisse, da es sich bei der Definition von Zugriffsrechten hierbei um den verbreitetsten Anwendungsfall handelt. Es ist jedoch ebenfalls möglich, die Zugriffsrechte auf Dateipfade zu beschränken.

[calendar:/projects/calendar/manager.ics]
harry = rw
sally = r


[51] Ein in diesem Buch häufiges Thema!