Die Authentifizierung mit VisualSVN 2.5.16 macht mich verrückt - funktioniert nicht in MS Windows 7

1394
Minok

VisualSVN 2.5.16 auf einem Server, Tortoise SVN 1.8.1 als Client auf einem Entwicklungscomputer.

Ich habe Berechtigungen für den VisualSVN Server Manger eingerichtet, um jemandem Zugriff auf ein Repo zu gewähren. Die Berechtigungen scheinen sich in der Oberfläche zum Durchsuchen von Repos zu widerspiegeln, nicht jedoch in den Aktualisierungs- / Festschreibungsaktionen von TortoiseSVN, wenn sie mit dem VisualSVN-Server kommunizieren.

Beispiel: Ich habe an dem Projekt gearbeitet, an dem ich seit Monaten gearbeitet habe, und teste - Entfernen Sie meine Berechtigungen im VisualSVN-Servermanager, sodass alle Benutzer über keinen Zugriff verfügen und die Entwicklergruppe über keinen Zugriff verfügt. IE no on hat an dieser Stelle Zugriff. Trotzdem kann ich immer noch eine Testdatei erstellen und an das Repo übergeben. Dann gehen Sie und löschen Sie die Datei aus dem Repo und bestätigen Sie diese. Ich kann anscheinend keine Berechtigungen für das Lesen oder Schreiben des Repos widerrufen.

Durch die Änderung wurde das Repository jetzt im "Repository Browser" von TortoiseSVN angezeigt (dh ich kann den Baumast nicht sehen, in dem ich meine Berechtigungen entfernt habe), aber die Aktualisierungs- / Festschreibungsaktionen aus dem Windows 7-Dateiexplorer-Kontextmenü funktionieren weiterhin einwandfrei .

Ich frage mich, ob die selbe Art der Seltsamkeit es ist, die meinen Kollegen daran hindert, auf das Repository zuzugreifen, um Änderungen vorzunehmen, obwohl er explizit Lese- / Schreibberechtigungen für das andere Repository erhalten hat, an dem er gerade arbeitet.

Das Hauptproblem, das ich zu lösen versuche, ist der, warum ein Kollege nur Lesezugriff auf einen Teil des Repositorys hat, in dem nur zwei Zugriffsmodi gewährt werden: "Kein Zugriff" für "Jeder" und "Lese- / Schreibzugriff" für unsere Dev-Gruppe und er explizit. Er authentifiziert sich für VisualSVN mit dieser expliziten Anmeldung, erhält jedoch nur Lesezugriff. Laut den VisualSVN-Dokumenten würde ihm dadurch, dass seinem Namen explizit Lese- / Schreibzugriff gewährt wird, dies über jegliche Vererbung oder den Zugriff aller Benutzer auf den Repository-Ordner gewährt.

Zwischen VisualSVN Standard Edition mit expliziten Konten und TortoiseSVN unter Windows 7 ist etwas Ungewöhnliches im Spiel.

0
hast du den Visual SVN Server 2.7 oder 3.0 ausprobiert? Aktualisieren Sie auch TSVN auf 1.8.8 magicandre1981 vor 9 Jahren 0

1 Antwort auf die Frage

0
bahrep

Beispiel: Ich habe an dem Projekt gearbeitet, an dem ich seit Monaten gearbeitet habe, und teste - Entfernen Sie meine Berechtigungen im VisualSVN-Servermanager, sodass alle Benutzer über keinen Zugriff verfügen und die Entwicklergruppe über keinen Zugriff verfügt. IE no on hat an dieser Stelle Zugriff. Trotzdem kann ich immer noch eine Testdatei erstellen und an das Repo übergeben. Dann gehen Sie und löschen Sie die Datei aus dem Repo und bestätigen Sie diese. Ich kann anscheinend keine Berechtigungen für das Lesen oder Schreiben des Repos widerrufen.

Ich denke, Sie haben eine Zugriffsregel auf der Root-Ebene, die Ihrem Konto Lese- / Schreibzugriff gewährt. Haben Sie eine Lese- / Schreibregel auf der übergeordneten Ebene? ZB eine Regel für alle. Wenn Sie dies tun, wechseln Sie den Zugriff auf Kein Zugriff oder entfernen Sie die Regel vollständig. Andernfalls kann die Read / Write-Zugriffsregel für Jeder wirksam werden, wenn Sie eine Repository-URL mit ungültigem Zeichen eingeben.

Vor Version 1.7 behandelte Apache Subversion die Namen und Pfade des Repository zu Zwecken der Zugriffskontrolle in Groß- und Kleinschreibung, indem sie intern in Kleinbuchstaben konvertiert wurden, bevor sie mit dem Inhalt Ihrer Zugriffsdatei verglichen wurden. Es macht jetzt diese Vergleiche case-sensitive. Siehe Apache Subversion 1.7. Versionshinweise unter http://subversion.apache.org/docs/release-notes/1.7.html#case-sensitive-authz .

Um die möglichen Sicherheitsprobleme zu beheben, sollten Sie den "Lese- / Schreibzugriff" aller Benutzer aus dem Repository-Stamm entfernen.

ANMERKUNG: Das Problem betrifft nur den Authentifizierungs- / Autorisierungstyp von Subversion und wird nicht mit der Windows-Authentifizierung / Autorisierung (Basis und / oder Integriert) reproduziert. Reproduziert nicht mit VisualSVN Server 2.6 und neuer.

VisualSVN 2.5.16 auf einem Server, Tortoise SVN 1.8.1 als Client auf einem Entwicklungscomputer.

Es ist sinnvoll, den Server und den Client auf dem neuesten Stand zu halten, zumindest innerhalb der aktuell verwendeten Version:

Verwandte Probleme