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.

Das Netzwerkmodell
Zurück  Kapitel 3. Fortgeschrittene Themen  Weiter

Das Netzwerkmodell

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 Anmeldung und die Berechtigung handhabt.

Anfragen und Antworten

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 „Projektarchive adressieren“).

[Tipp] Tipp

Rufen Sie svn --version auf, um zu sehen, welche URL-Schemas und Protokolle versteht.

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

Client-Zugangsdaten

Viele Subversion-Server sind so konfiguriert, dass sie eine Authentifikation benötigen. Manchmal sind anonyme Leseoperationen erlaubt, wohingegen Schreiboperationen authentifiziert sein müssen. In anderen Fällen benötigen Lese- und Schreiboperationen gleichermaßen eine Authentifikation. Die unterschiedlichen Server-Optionen von Subversion verstehen unterschiedliche Authentifikationsprotokolle, aus Anwendersicht jedoch bedeutet Authentifikation normalerweise Anwendernamen und Passwörter. Subversion-Clients bieten verschiedene Möglichkeiten, die Zugangsdaten eines Anwenders abzurufen und zu speichern, vom interaktiven Abfragen des Anwendernamens und Passworts bis zu verschlüsselten oder unverschlüsselten Zwischenspeichern auf der Platte.

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!“ Keine Angst! Das hört sich schlimmer an, als es ist. Die folgenden Abschnitte erörtern die verschiedenen Arten der Zugangsdatenzwischenspeicherung, die Subversion verwendet, wann es sie verwendet und wie man diese Funktionalität ganz oder teilweise abstellen kann.

Zwischenspeichern von Zugangsdaten

Subversion bietet Abhilfe gegen die lästige Notwendigkeit, dass Anwender jedes Mal Ihren Benutzernamen und das Passwort eintippen müssen. Standardmäßig werden die Zugangsdaten mit einer Kombination des Rechnerenamens des Servers, dem Port und der Zugangsregion auf Platte gespeichert, sobald der Kommandozeilen-Client erfolgreich auf eine Authentisierungsaufforderung des Servers antwortet. Auf diesen Zwischenspeicher wird dann künftig zugegriffen, was eine erneute Eingabe der Zugangsdaten durch den Anwender vermeidet. Falls scheinbar passende Zugangsdaten nicht im Zwischenspeicher verfügbar sind oder die zwischengespeicherten Daten nicht authentifiziert werden können, wird der Client den Anwender wieder standardmäßig zur Eingabe der notwendigen Informationen auffordern.

Die Entwickler von Subversion erkennen, das auf Platte zwischengespeicherte Zugangsdaten ein Sicherheitsrisiko darstellen können. Um dieses zu verringern, arbeitet Subversion mit den durch das Betriebssystem und die Umgebung bereitgestellten Mechanismen, um das Risiko der Kompromittierung dieser Daten zu minimieren.

  • Unter Windows speichert der Subversion-Client Passwörter im Verzeichnis %APPDATA%/Subversion/auth/. 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 existiert kein einzelner standardisierter „Schlüsselring“-Dienst. Der Subversion-Client weiß aber, wie er Passwörter sicher mit den Diensten „GNOME Keyring“ und „KDE Wallet“ speichern kann. Bevor unverschlüsselte Passwörter im Zwischenspeicherbereich ~/.subversion/auth/ gespeichert werden, fragt der Subversion-Client den Anwender, ob er das machen darf. Beachten Sie, dass der auth/-Bereich zur Zwischenspeicherung immer noch über Zugangsrechte geschützt ist, so dass nur der Anwender (Eigentümer) die dortigen Daten lesen kann und nicht die gesamte Welt. Die betriebssystemeigenen Dateizugriffsrechte schützen die Passwörter vor anderen nicht-administrativen Anwendern auf dem selben System, vorausgesetzt, sie haben keinen direkten physischen Zugriff zum Speichermedium des Heimverzeichnisses oder dessen Sicherungen.

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.

Unterbinden der Zwischenspeichrung von Passwörtern

Wenn Sie eine Subversion-Operation durchführen, die von Ihnen eine Authentisierung verlangt, versucht Subversion standardmäßig, Ihre Zugangsdaten verschlüsselt auf Platte zwischenzuspeichern. Auf manchen Systemen kann es sein, dass Subversion Ihre Zugangsdaten nicht verschlüsseln kann. In diesen Situationen, fragt Subversion nach, ob Sie möchten, dass die Zugangsdaten im Klartext auf Platte gespeichert werden:

$ svn checkout https://host.example.com:443/svn/private-repo
-----------------------------------------------------------------------
ACHTUNG! Ihr Password für den Anmeldungstext (realm)

   <https://host.example.com:443> Subversion Repository

kann auf der Platte nur unverschlüsselt gespeichert werden! Es wird
empfohlen, falls möglich Ihr System so zu konfigurieren, dass Subversion
Passwörter verschlüsselt speichern kann. Siehe die Dokumentation für
Details.

Sie können ein weiteres Anzeigen dieser Warnung verhindern, indem Sie
den Wert der Option »store-plaintext-passwords« in
»/tmp/servers«
entweder auf »ja« oder »nein« setzen.
-----------------------------------------------------------------------
Passphrase unverschlüsselt speichern (ja/nein)?

Wenn Sie die Bequemlichkeit nutzen wollen, nicht ständig für künftige Operationen Ihr Passwort erneut eingeben zu müssen, können Sie mit ja auf diese Aufforderung antworten. Falls Sie Bedenken haben, Ihr Passwort im Klartext zwischenzuspeichern und nicht jedesmal erneut danach gefragt werden wollen, können Sie die Zwischenspeicherung von Passwörtern im Klartext entweder permanent oder abhängig vom Server abstellen.

[Warnung] Warnung

Wenn Sie sich Gedanken dazu machen, wie Sie das Zwischenspeichern von Passwörtern unter Subversion verwenden wollen, sollten Sie die Richtlinien berücksichtigen, die für Ihren Rechner gelten – viele Firmen haben strenge Regeln für die Speicherung der Zugangsdaten von Mitarbeitern.

Um das Zwischenspeichern von Passwörtern im Klartext permanent zu unterbinden, fügen Sie die Zeile store-plaintext-passwords = no im Abschnitt [global] der Konfigurationsdatei servers auf dem lokalen Rechner ein. Um die Zwischenspeicherung von Passwörtern für einen bestimmten Server zu unterbinden, verwenden Sie dieselbe Einstellung im entsprechenden Gruppenabschnitt der Konfigurationsdatei servers. (Für Details, siehe „Konfigurationsoptionen“ in Kapitel 7, Subversion an Ihre Bedürfnisse anpassen.)

Um die Zwischenspeicherung von Passwörtern vollständig für irgendeine einzelne Subversion-Kommandozeilenoperation abzuschalten, übergeben Sie dem Befehl die Option --no-auth-cache. Um die Zwischenspeicherung permanent vollständig zu unterbinden, fügen Sie der Konfigurationsdatei für Subversion auf dem lokalen Rechner die Zeile store-passwords = no hinzu.

Entfernen zwischengespeicherter Zugangsdaten

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.

Anmeldung über die Kommandozeile

Alle Kommandozeilenaktionen von Subversion erlauben die Optionen --username und --password, die es Ihnen ermöglichen, Ihren Anwendernamen bzw. Ihr Passwort anzugeben, damit Subversion Sie nicht nach diesen Informationen fragen muss. Das ist besonders dann praktisch, wenn Sie Subversion aus einem Script heraus aufrufen wollen, und Sie sich nicht darauf verlassen können, dass Subversion in der Lage ist, gültige zwischengespeicherte Zugangsdaten für Sie zu finden. Diese Optionen sind auch dann hilfreich, falls Subversion bereits Anmeldedaten von Ihnen zwischengespeichert hat, aber diese nicht von Ihnen verwendet werden sollen. Vielleicht teilen sich mehrere Systemanwender ein Zugangskonto, haben jedoch verschiedene Identitäten unter Subversion. Sie können die Option --password weglassen, falls Sie möchten, dass Subversion nur den angegebenen Anwendernamen verwenden soll, Sie aber trotzdem auffordern soll, das Passwort dieses Anwenders einzugeben.

Schlusswort zur Anmeldung

Ein letztes Wort zum Anmeldungsverhalten 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 deren Verwendung 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] Anmerkung

Ein verbreiteter Fehler ist die Fehlkonfigurierung eines Servers, so dass er nie eine Aufforderung zur Authentisierung ausgibt. Falls Benutzer dann die Optionen --username und --password an den Client übergeben, wundern sie sich, dass sie nie verwendet werden, d.h., es sieht so aus, dass neue Revisionen anonym übergeben worden sind!

An dieser Stelle sei abschließend zusammengefasst, wie sich ein Subversion-Client bei Erhalt einer Aufforderung zur Authentisierung verhält.

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

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

  3. 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).

Zurück  Nach oben  Weiter
Änderungslisten  Zum Anfang  Zusammenfassung