Sowohl Apache als auch svnserve können Anwendern Zugriffsrechte 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 Zugangsdatei befindet, 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]](images/warning.png)
|
Warnung |
|---|---|
|
Vor Version 1.7 hat Subversion bei Namen und Pfaden von Projektarchiven nicht die Groß- oder Kleinschreibung beachtet, da sie vor dem Vergleich mit dem Inhalt der Zugangsdatei in Kleinbuchstaben umgewandelt wurden. Nun werden Vergleiche unter Berücksichtigung der Groß- und Kleinschreibung vorgenommen. Falls Sie eine ältere Version auf Subversion 1.7 aktualisiert haben, sollten Sie Ihre Zugangsdateien auf die korrekte Groß- und Kleinschreibung überprüfen. |
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 |
|---|---|
|
mod_dav_svn bietet eine Direktive
<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
|
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 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