Manchmal müssen Sie verstehen, wie Ihr Subversion-Client mit
seinem Server kommuniziert. Die Netzwerkschicht von Subversion
ist abstrahiert, was bedeutet, dass die Clients von Subversion
das gleiche allgemeine Verhalten an den Tag legen, egal mit
welcher Art von Server sie zusammenarbeiten. Ob sie im
HTTP-Protokoll (http://
) mit dem Apache
HTTP-Server oder im maßgeschneiderten Subversion Protokoll
(svn://
) mit svnserve
sprechen, das grundlegende Netzwerkmodell ist das selbe. In
diesem Abschnitt werden wir die Grundlagen dieses
Netzwerkmodells erläutern, auch wie Subversion die
Authentifizierung und die Autorisierung handhabt.
Den größten Teil seiner Zeit verbringt der Subversion-Client mit der Verwaltung von Arbeitskopien. Wenn er jedoch Informationen von einem entfernten Projektarchiv benötigt, stellt er eine Anfrage über das Netz, und der Server erwiedert mit einer passenden Antwort. Die Details des Netzwerkprotokolls sind dem Benutzer verborgen – der Client versucht, auf einen URL zuzugreifen, und abhänging vom URL-Schema wird ein bestimmtes Protokoll verwendet, um mit dem Server Verbindung aufzunehmen (siehe Anmerkung Projektarchiv-URLs).
Tipp | |
---|---|
Rufen Sie |
Wenn der Server-Prozess eine Anfrage eines Clients erhält, verlangt er häufig, dass der Client sich identifiziert. Er sendet eine Authentisierungsaufforderung an den Client und der Client antwortet, indem er Zugangsdaten zurückschickt. Sobald die Authentifizierung abgeschlossen ist, antwortet der Server mit den ursprünglich vom Client angefragten Informationen. Beachten Sie, dass dieses System sich von solchen wie CVS unterscheidet, bei denen der Client von sich aus dem Server Zugangsdaten anbietet („sich anmeldet“), bevor überhaupt eine Anfrage erfolgt. In Subversion werden die Zugangsdaten vom Server „eingezogen“, indem der Client zum passenden Zeitpunkt aufgefordert wird, und nicht indem der Client sie „abliefert“. Das macht gewisse Operationen eleganter. Wenn ein Server beispielsweise so konfiguriert ist, dass jedem auf der Welt erlaubt ist, ein Projektarchiv zu lesen, wird der Server niemals eine Authentisierungsaufforderung ausgeben, wenn ein Client svn checkout versucht.
Falls die einzelnen Netzwerkanfragen des Clients zur
Erstellung einer neuen Revision im Projektarchiv führen (z.B.
svn commit), verwendet Subversion den mit
diesen Anfragen verknüpften authentifizierten Benutzernamen
als Autor der Revision. Das bedeutet, dass der Name des
authentifizierten Benutzers als Wert der Eigenschaft
svn:author
der neuen Revision zugewiesen
wird (siehe „Subversion-Eigenschaften“). Falls der
Client nicht authentifiziert wurde (d.h., falls der Server
niemals eine Authentisierungsaufforderung ausgegeben hat),
bleibt die Revisionseigenschaft svn:author
leer.
Viele Server sind so konfiguriert, dass sie vor jeder
Anfrage eine Authentisierung benötigen. Für Benutzer wäre es
sehr lästig, wenn sie jedes Mal das Passwort eingeben müssten.
Glücklicherweise hat der Subversion-Client hierfür eine Abhilfe:
ein eingebautes System zum Zwischenspeichern der Zugangsdaten
auf Platte. Standardmäßig legt der Kommandozeilen-Client die
Zugangsdaten immer im privaten Laufzeitkonfigurationsbereich
des Benutzers ab (~/.subversion/auth/
auf
Unix-ähnlichen Systemen oder
%APPDATA%/Subversion/auth/
unter Windows;
siehe „Laufzeit-Konfigurationsbereich“ für Details zum
Laufzeitkonfigurationssystem), wenn er erfolgreich auf die
Authentisierungsanfrage des Servers antwortet. Die gültigen
Zugangsdaten werden auf Platte zwischengespeichert und mit
einer Kombination aus dem Rechnernamen des Servers, dem Port
und dem Anmeldebereich referenziert.
Wenn der Client eine Authentisierungsaufforderung empfängt, schaut er zunächst nach den passenden Zugangsdaten im Cache des Benutzers auf Platte. Falls passend erscheinende Zugangsdaten nicht verfügbar sind oder die zwischengespeicherten Zugangsdaten letzlich nicht für eine Authentisierung ausreichen sollten, wird der Client standardmäßig den Benutzer zur Eingabe der notwendigen Informationen auffordern.
Der sicherheitsbewussten Leser wird an dieser Stelle sofort einen Grund für Besorgnis erkennen. „Passwörter auf der Platte speichern? Das ist schrecklich! So etwas sollte man nie machen!“
Die Entwickler von Subversion erkennen die Zulässigkeit dieser Besorgnis, und so arbeitet Subversion mit den durch das Betriebssystem und die Umgebung bereitgestellten Mechanismen, um das Risiko der Kompromittierung dieser Daten zu minimieren. Hier ist eine Aufschlüsselung, was das für die Benutzer der verbreitetsten Betriebssysteme bedeutet:
Unter Windows 2000 und dessen Nachfolger verwendet der Subversion-Client die Standard-Kryptographiedienste von Windows, um das Passwort auf Platte zu verschlüsseln. Da der Schlüssel durch Windows verwaltet wird und mit den benutzereigenen Zugangsdaten verknüpft ist, kann nur der Benutzer selbst das zwischengespeicherte Passwort entschlüsseln. (Beachten Sie, dass beim Zurücksetzen des Windows-Benutzerkonto-Passworts durch einen Administrator alle zwischengespeicherten Passwörter nicht mehr zu entschlüsseln sind. Der Subversion-Client verhält sich dann so, als wären sie nicht vorhanden und fragt die Passwörter gegebenenfalls ab.)
Unter Mac OS X speichert der Subversion-Client auf ähnliche Weise alle Passwörter des Projektarchivs im Login-Keyring (durch den Keychain-Dienst verwaltet), der durch das Passwort des Benutzerkontos geschützt ist. Benutzerseitige Einstellungen können zusätzliche Richtlinien in Kraft setzen, etwa, dass das Benutzerkontopasswort jedesmal eingegeben werden muss, wenn das Passwort von Subversion verwendet wird.
Für andere Unix-ähnliche Betriebssysteme existieren
keine standardisierten
„Schlüsselring“-Dienste. Jedoch ist der
auth/
-Bereich zur Zwischenspeicherung
immerhin über Zugangsrechte geschützt, so dass nur der
Benutzer (Eigentümer) die dortigen Daten lesen kann und
nicht die gesamte Welt. Die betriebssystemeigenen
Dateizugriffsrechte schützen die Passwörter.
Natürlich sind keine dieser Mechanismen perfekt für den echt Paranoiden. Für die Leute, die Bequemlichkeit für die größte Sicherheit opfern möchten, bietet Subversion verschiedene Möglichkeiten, das System der Zwischenspeicherung ganz abzuschalten.
Übergeben Sie die Option --no-auth-cache
,
um die Zwischenspeicherung für einen einzelnen Befehl
abzuschalten:
$ svn commit -F log_msg.txt --no-auth-cache Anmeldebereich: <svn://host.example.com:3690> example realm Benutzername: joe Passwort für »joe«: Hinzufügen newfile Übertrage Daten . Revision 2324 übertragen. # Das Passwort war nicht Zwischengespeichert, also werden wir beim zweiten Mal gefragt $ svn delete newfile $ svn commit -F new_msg.txt Anmeldebereich: <svn://host.example.com:3690> example realm Benutzername: joe …
Wenn Sie aber die Zwischenspeicherung der Zugangsdaten
dauerhaft unterbinden wollen, können Sie die Datei
config
in Ihrem
Laufzeitkonfigurationsbereich bearbeiten und die Option
store-auth-creds
auf no
setzten. Das verhindert die Speicherung der Zugangsdaten für
alle Ihre Interaktionen mit Subversion auf dem betroffenen
Rechner. Das kann auch auf alle Benutzer ausgeweitet werden,
indem der systemweite Konfigurationsbereich (beschrieben in
„Aufbau des Konfigurationsbereichs“) bearbeitet
wird.
[auth] store-auth-creds = no
Manchmal möchten Benutzer bestimmte Zugangsdaten aus dem
Zwischenspeicher entfernen. Hierzu müssen Sie in den
auth/
-Bereich gehen und die entsprechende
Zwischenspeicherdatei manuell löschen. Die Zugangsdaten werden
in individuellen Dateien zwischengespeichert; falls Sie in
jede Datei hineinsehen, werden Sie Schlüssel und Werte
entdecken. Der Schlüssel svn:realmstring
beschreibt den bestimmten Anmeldebereich, zu dem die Datei
gehört:
$ ls ~/.subversion/auth/svn.simple/ 5671adf2865e267db74f09ba6f872c28 3893ed123b39500bca8a0b382839198e 5c3c22968347b390f349ff340196ed39 $ cat ~/.subversion/auth/svn.simple/5671adf2865e267db74f09ba6f872c28 K 8 username V 3 joe K 8 password V 4 blah K 15 svn:realmstring V 45 <https://svn.domain.com:443> Joe's repository END
Sobald Sie die passende Datei gefunden haben, können Sie sie einfach löschen.
Ein letztes Wort zum Authentifizierungsverhalten von
svn, im Besonderen bezüglich der Optionen
--username
und --password
.
Viele Unterbefehle des Clients akzeptieren diese Optionen,
jedoch ist es wichtig, zu verstehen, dass durch die Verwendung
dieser Optionen nicht automatisch
Zugangsdaten an den Server gesendet werden. Wie bereits
erörtert wurde, werden die Zugangsdaten vom Server
„eingezogen“, falls er es für notwendig hält; der
Client kann sie nicht nach belieben „abliefern“.
Wurde ein Benutzername und/oder ein Passwort als Optionen
mitgegeben, werden sie dem Server nur auf Verlangen vorgelegt.
Üblicherweise werden diese Optionen verwendet, um sich als ein
anderer Benutzer zu authentisieren als derjenige, den
Subversion standardmäßig gewählt hätte (etwa Ihr Anmeldename),
oder falls Sie die interaktive Abfrage vermeiden möchten (etwa
beim Aufruf von svn aus einem
Skript).
Anmerkung | |
---|---|
Ein verbreiteter Fehler ist die Fehlkonfigurierung eines
Servers, so dass er nie eine Aufforderung zur
Authentisierung ausgibt. Falls Benutzer dann die Optionen
|
An dieser Stelle sei abschließend zusammengefasst, wie sich ein Subversion-Client bei Erhalt einer Aufforderung zur Authentisierung verhält.
Zunächst prüft der Client, ob der Benutzer
irgendwelche Zugangsdaten als Kommandozeilenoptionen
(--username
und/oder
--password
) angegeben hat. Falls ja,
versucht der Client, diese Zugangsdaten zur
Authentisierung gegenüber dem Server zu
verwenden.
Falls keine Zugangsdaten als Kommandozeilenoptionen
angegeben worden sind oder die übergebenen ungültig waren,
verwendet der Client den Rechnernamen des Servers, den
Port und den Anmeldebereich, um damit im
Laufzeitkonfigurationsbereich auth/
nach passenden zwischengespeicherten Zugangsdaten zu
suchen. Falls solche vorhanden sind, probiert er, sich
hiermit zu authentisieren.
Falls letztendlich alle vorherigen Mechanismen keine
erfolgreiche Authentisierung des Benutzers gegen den
Server bewirken, greift der Client auf eine interaktive
Abfrage der Zugangsdaten zurück (sofern ihm das nicht
durch die Option --non-interactive
oder
client-spezifischer Äquivalente untersagt wurde).
Falls sich der Client durch irgendeine dieser Methoden erfolgreich authentisiert, versucht er, die Zugangsdaten auf der Platte zwischenzuspeichern (sofern der Benutzer dieses Verhalten nicht, wie oben beschrieben, unterbunden hat).