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.
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) hizugefügt
werden, die auf Ihre eigene Regeldatei 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 Regeldatei
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]. 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.
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]](images/tip.png)
|
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 Stern-Variable (*) verdient ebenso
besondere Erwähnung, da sie das einzige
Muster ist, das auf einen anonymen Anwender passt. Falls Sie
Ihren Server-Block für einen gemischten anonymen und
authentifizierten Zugriff konfiguriert haben, beginnen alle
Anwender mit anonymen Zugriff. Der Server sucht nach einem
für den Zugriffspfad definierten *-Wert; kann
er keinen finden, verlangt er echte Authentifizierung vom
Client.
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, sally, 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 die
erste passende Regel diejenige ist, die für
einen Anwender gilt. Im vorhergehenden Beispiel trifft die Regel
jane = r vor der Gruppenregel zu; obwohl Jane
Mitglied der Gruppe paint-developers ist (die
über Lese- und Schreibzugriff verfügt), bleibt Jane somit der
Schreibzugriff verwehrt.
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 führt eine nützliche Erweiterung in die
Syntax der Zugriffsdatei ein: Anwendernamen-Aliase. 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.