Multisuser Umgebungen sind nun in der UNIX Welt Sachen aus einer Zeit in der ich geboren wurde – dennoch ist bis zum heutigen Tag die Sache nicht ganz unproblematisch.
Subversion (svn) – Multiuseraccess auf Repository und Working Directory
Das Repository kann auf 4 Arten angesprochen werden:
- svn client auf regulärem (lokalen) Filesystem
- ssh-spawned svnserve Prozess
- svnserve Prozess
- Apache HTTP Prozess
Methode 1+2 laufen mit normeln Benutzerkennungen auf den Maschinen. Daher macht es Sinn für jedes Repository eine Gruppe zu definieren, welche Schreibberechtigung hat.
Wenn man eine normale POSIX Rechtestruktur zugrundelegt (keine ACL’s), dann müssen folgende Schritte ausgeführt werden.
1. Dem angelegten Repository Verzeichnis – meist auf dem svn Server unter /var/svn – müssen rekursiv alle Gruppenrechte (-bits) gegeben werden.
chmod -R g+rw /var/svn/<REPOSITORY>
2. Das sgid bit muss für dieses Respository etabliert werden, da die Benutzer unterschiedliche primäre Gruppen haben können.
chmod -R g+s /var/svn/<REPOSITORY>
3. Die umask muss auf dem subversion Server so eingestellt sein, dass die Gruppe immer Schreibrecht hat, bspw:
umask 0002
Damit funktionieren die beiden ersten Zugriffsmethoden. Die dritte und vierte Methode (HTTP) führt die Operationen immer mit der Benutzerkennung des Dämonenprozesses durch. Der Benutzer muss sich an diesem Prozess authentifizieren – seine Kennung wird innerhalb der svn Files mitdurchgeschleust (svn blame zeigt damit immer den richtigen Author an).
Somit erfordern diese Zugriffsarten nochmals Anpassungen
4. Die Ownership des Repositories wird auf den Owner der HTTP/svnserver Dämonen angepasst. Dieser Benutzer muss allerdings auch Mitglied der Gruppe sein, die Schreibzugriff auf das Repository hat.
5. Bei HTTP muss man ev. die Benutzerkennung des Prozesses anpassen (siehe 4.). Falls mehrere HTTP Dienste laufen, weicht man auf einen virtuellen Host aus, der auf einem gesonderten Port läuft.
6. Die Dämonen müssen ebenfalls die unter 3. genannte umask respektieren – oder Sie muss angepasst werden durch ändern der AP_SUEXEC_UMASK Variable
Das war’s auf Repository Seite – ich bin der Meinung, die Einschränkungen pro Repository sollten reichen, falls aber eine noch filigranere Abstufung der Rechte (händisches ACL) gewünscht ist, muss man die Path-Based Authorizations in svnserve.conf benutzen.
Diese greifen beim Zugriff mit den Methoden 1-3 automatisch wenn auch kostspielig was die Performance betrifft.
Für den HTTP Zugriff muss serverseitig das Modul mod_authz_svn geladen und in der Konfiguration AuthzSVNAccessFile eingetragen werden.
Beim Zugriff auf das Working Directory wird’s undefinierter
Eigentlicht ist das working directory eher pro user gedacht auch wenn dies nie explizit erwähnt wird.
In einem Working Directory auf einem POSIX (UNIX) Rechner macht der svn client folgendes:
- Die Struktur im .svn Unterverzeichnis (zeigt den Zustand des working directories an) wird unabhängig von der umask angelegt, d.h. zentrale Dateien habe immer nur ein Leseflag.
- Wenn die Rechtestruktur im working directory ebenfalls so angelegt ist, dass Mitglieder einer Gruppe immer Schreiben können, sollte es zum Konflikt kommen wenn Dateien im .svn Verzeichnis geändert werden….
- … denn bei einem svn commit wechselt die Ownership einiger Dateien im .svn Verzeichnis auf denjeniegen der diese Operation durchgefüht hat. Der svn UNIX client macht folgendes:
- betreffende Datei kopieren (..tmp)
- diese Datei dann beschreiben.
- die zu ersetzende Datei löschen
- die temporäre Datei wieder zurückzukopieren (mv Operation)
All diese Punkte erfordern nur die Schreibberechtigung auf dem .svn Verzeichnis
Schwieriger wird’s bei einem Windows svn client (Tortoise oder Kommandotool)
die oben genannten 4 Punkte greifen nicht, denn unter Windows haben wir statt dem einfachen POSIX Rechtemodell die Windows ACL’s.
Daher muss gewährleistet sein, dass alle Benutzer der zugreifenden Gruppe die ACL’s
- Take Ownership
- Change Permissions
gesetzt haben – Schreibberechtigung sowieso vorrausgesetzt.
Dann geht es auch hier – dieses Verfahren hat aber seine Grenzen wenn das working directory auf einem SAMBA Server liegt, der nur einfache POSIX Rechte auf Windows ACL’s mappt und somit diese beiden ACL Flags nicht setzen kann.
Hier könnte höchstens noch ein Samba Server mit aktivierten ACL’s helfen. Allerdings wäre die Kompatibilität zwischen Windows – POSIX und NFS4 ACL’s zu testen. Eventuell werden die neuen NFS4 ACL’s der neue POSIX Standard, was wegen der besseren Kompatibilität zu den Windows ACL’s zu begrüßen wäre.
