Welche Berechtigungen müssen für das SVN-Stammverzeichnis festgelegt werden?

Welche Berechtigungen müssen für das SVN-Stammverzeichnis festgelegt werden?

Ich versuche, über Apache einen Remotezugriff auf den SVN-Server bereitzustellen. Die Situation kann wie folgt dargestellt werden:

/root
    /public-project
        /trunk
        /branches
    /restricted-project
        /trunk
        /branches

Es gibt nur ein Repository, das beide Projekte enthält.

Die öffentlichen Projekte können von jedem eingesehen werden (nur angesehen, nie geändert). Die eingeschränkten Projekte können nur von Benutzern gelesen/geändert werden, die zu bestimmten Gruppen gehören. Die Konfiguration ist wie folgt:

<Location "/root">
  DAV svn
  SVNPath [...]
  SVNIndexXSLT [...]
  [...]
  <LimitExcept PROPFIND OPTIONS REPORT>
    require ldap-group CN=SVN Administrators,OU=Subversion,DC=example,DC=com
  </LimitExcept>
</location>

<Location "/root/public-project">
  <LimitExcept GET PROPFIND OPTIONS REPORT>
    require ldap-group CN=Project1 Contributors,OU=Subversion,DC=example,DC=com
  </LimitExcept>
</location>

<Location "/root/restricted-project">
  require ldap-group CN=Project2 Contributors,OU=Subversion,DC=example,DC=com
</location>
  1. Ist es sicher genug oder besteht die Möglichkeit, dass ein Gast auf vertrauliche Informationen des eingeschränkten Projekts zugreift?

  2. Beim Aktualisieren der Quelle des öffentlichen Projekts über SVN erhalte ich die folgende Fehlermeldung:

    Nicht berechtigt, das Stammverzeichnis des Bearbeitungsvorgangs zu öffnen

    Apache error.log zeigt die folgenden Elemente:

    Beim Ausführen des Update-Report-Editors ist ein Fehler aufgetreten [500, #220000]
    Keine Berechtigung zum Öffnen des Stammverzeichnisses der Bearbeitungsoperation [500, #220000]

    Was access.log betrifft, zeigt es, dass der SVN-Client eine Reihe von PROPFIND(Antwort: HTTP 207) und OPTIONS(Antwort: HTTP 200) erzeugt hat, und schließlich:

    "REPORT /root/!svn/vcc/default HTTP/1.1" 500 241

    Was muss ich tun, um dieses Problem zu lösen? Z. B. den öffentlichen Lesezugriff für das öffentliche Projekt aktivieren und gleichzeitig den eingeschränkten Zugriff vor nicht autorisierten Benutzern verbergen?

Hinweis: Durch die Gewährung des GET-Privilegs /rootkann ein Gast die Quelle des öffentlichen Projekts laden, das öffentliche Verhalten wird jedoch auch zum Standardverhalten. Ich würde den Zugriff lieber einschränken und ihn nur auf Knoten gewähren, die öffentliche Projekte enthalten.

Antwort1

Ich habe eine neue Umgebung von Grund auf neu erstellt und mit der Konfiguration gespielt, aber es scheint, dass dienurDer beste Weg besteht darin, standardmäßig alles öffentlich zu machen und dann bestimmte Projekte explizit einzuschränken.

Dies ist aus Sicherheitsgründen völliger Unsinn, insbesondere in einem Kontext, in dem viele Projekte erstellt werden, die manchmal nicht vollständig automatisiert sind, sodass leicht ein Fehler passieren kann, wenn vergessen wird, eine Einschränkung festzulegen. Dies zwingt jedoch auch dazu, die Automatisierung weiter voranzutreiben, was nur von Vorteil sein kann.

Wenn jemand mit den Einstellungen spielen möchte, kann ich die aktuell verwendete Konfiguration bereitstellen.

verwandte Informationen