{"id":58,"date":"2007-11-30T19:49:15","date_gmt":"2007-11-30T17:49:15","guid":{"rendered":"http:\/\/www.instruyete.org\/?p=58"},"modified":"2007-11-30T19:49:15","modified_gmt":"2007-11-30T17:49:15","slug":"multiuser-umgebung-und-subversion","status":"publish","type":"post","link":"https:\/\/www.instruyete.org\/?p=58","title":{"rendered":"Multiuser Umgebung und subversion"},"content":{"rendered":"

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.<\/p>\n

Subversion (svn) – Multiuseraccess auf Repository und Working Directory<\/h2>\n

Das Repository kann auf 4 Arten angesprochen werden:<\/p>\n

    \n
  1. svn client auf regul\u00e4rem (lokalen) Filesystem<\/li>\n
  2. ssh-spawned svnserve Prozess<\/li>\n
  3. svnserve Prozess<\/li>\n
  4. Apache HTTP Prozess<\/li>\n<\/ol>\n

    Methode 1+2 laufen mit normeln Benutzerkennungen auf den Maschinen. Daher macht es Sinn f\u00fcr jedes Repository eine Gruppe zu definieren, welche Schreibberechtigung hat.
    \nWenn man eine normale POSIX Rechtestruktur zugrundelegt (keine ACL’s), dann m\u00fcssen folgende Schritte ausgef\u00fchrt werden.<\/p>\n

    1. Dem angelegten Repository Verzeichnis – meist auf dem svn Server unter \/var\/svn<\/strong> – m\u00fcssen rekursiv alle Gruppenrechte (-bits) gegeben werden.<\/p>\n

    chmod -R g+rw \/var\/svn\/<REPOSITORY><\/code><\/p>\n

    2. Das sgid<\/strong> bit muss f\u00fcr dieses Respository etabliert werden, da die Benutzer unterschiedliche prim\u00e4re Gruppen haben k\u00f6nnen.<\/p>\n

    chmod -R g+s \/var\/svn\/<REPOSITORY><\/code><\/p>\n

    3. Die umask<\/strong> muss auf dem subversion Server so eingestellt sein, dass die Gruppe immer Schreibrecht hat, bspw:<\/p>\n

    umask 0002<\/code><\/p>\n

    Damit funktionieren die beiden ersten Zugriffsmethoden. Die dritte und vierte Methode (HTTP) f\u00fchrt die Operationen immer mit der Benutzerkennung des D\u00e4monenprozesses durch<\/em>. Der Benutzer muss sich an diesem Prozess authentifizieren – seine Kennung wird innerhalb der svn Files mitdurchgeschleust (svn blame<\/strong> zeigt damit immer den richtigen Author an).<\/p>\n

    Somit erfordern diese Zugriffsarten nochmals Anpassungen<\/p>\n

    4. Die Ownership des Repositories wird auf den Owner der HTTP\/svnserver D\u00e4monen angepasst. Dieser Benutzer muss allerdings auch Mitglied der Gruppe sein, die Schreibzugriff auf das Repository hat.<\/p>\n

    5. Bei HTTP muss man ev. die Benutzerkennung des Prozesses anpassen (siehe 4.). Falls mehrere HTTP Dienste laufen, weicht man auf einen virtuellen Host<\/em> aus, der auf einem gesonderten Port l\u00e4uft.<\/p>\n

    6. Die D\u00e4monen m\u00fcssen ebenfalls die unter 3. genannte umask respektieren – oder Sie muss angepasst werden durch \u00e4ndern der AP_SUEXEC_UMASK<\/strong> Variable<\/p>\n

    Das war’s auf Repository Seite – ich bin der Meinung, die Einschr\u00e4nkungen pro Repository sollten reichen, falls aber eine noch filigranere Abstufung der Rechte (h\u00e4ndisches ACL) gew\u00fcnscht ist, muss man die Path-Based Authorizations<\/em> in svnserve.conf<\/strong> benutzen.<\/p>\n

    Diese greifen beim Zugriff mit den Methoden 1-3 automatisch wenn auch kostspielig was die Performance betrifft.<\/p>\n

    F\u00fcr den HTTP Zugriff muss serverseitig das Modul mod_authz_svn<\/strong> geladen und in der Konfiguration AuthzSVNAccessFile<\/strong> eingetragen werden.<\/p>\n

    Beim Zugriff auf das Working Directory wird’s undefinierter<\/h2>\n

    Eigentlicht ist das working directory eher pro user gedacht auch wenn dies nie explizit erw\u00e4hnt wird.<\/p>\n

    In einem Working Directory auf einem POSIX (UNIX) Rechner macht der svn client folgendes:<\/p>\n