Hallo Mathias,
Dann könnte ja jeder, der sich remote als root ausgibt dem Benutzer root auf dem CVS-Server Dateien unterschieben.
Ok, das leuchtet mir ein. Ich dachte nur, dass auf einem Stand-alone Rechner für CVS root genauso ein "normaler" Benutzer ist wie jeder andere auch. Außerdem habe ich für meinen CVS-Einsatz nur die Umgebungsvariable CVSROOT im globalen Profile gesetzt -- ein Server läuft bei mir nicht!
Ich bin mir nicht zu 100% sicher, aber ich denke, daß CVS als Client/Server-SW immer einen Server laufen hat, auch lokal.
Dann startest Du als 'cvs' ein xterm o.ä. und wechselst in eines der Arbeitsverzeichnisse (wo sich ein Verzeichnis CVS mit einer Root-Datei mit dem Inhalt ':local:<Pfad-zum-Repository>' befindet). Jetzt ist es an der Zeit in dem xterm root zu werden. Dann sollte ein commit funktionieren.
Werde ich durchtesten. Ist es egal wie diese Root-Datei heißt?
T'schuldigung, die Datei heißt "Root" und liegt in jedem Verzeichnis "CVS" unter Deinen Arbeitsverzeichnissen.
2a) Man macht einen Benutzer zum "sudoer" (man sudo bzw. man sudoers), d.h. man überträgt einem vertrauenswürdigen Benutzer gewisse hoheitliche Aufgaben, so daß er z.B. Dateien in /etc schreiben darf.
Das scheint mir der praktischste Ansatz für lokales Arbeiten zu sein. Werde ich auch ausprobieren.
Ich finde die manpages für sudo und sudoers allerdings etwas kompliziert und daher aufwendig zum einarbeiten.
root macht weiterhin die Systemkonfiguration. Nun muß root nur noch die veränderten Dateien in das Arbeitsverzeichnis der CVS-Verwalters kopieren, d.h. die Arbeitsdateien dort überschreiben. [...] Wenn root sich "verkonfiguriert" hat muß der CVS-Verwalter die zuletzt als funktionierend bekannten Konfigurationsdateien aus dem Repository ins Arbeitsverzeichnis holen, von wo sich root die Dateien wieder abholt.
Ich sehe dabei nur zwei kritische Punkte: (i) Root muss nur(!) bei den Permissions aufpassen, wenn er Dateien des CVS-Verwalters verwendet.
Wenn root die Dateien im Arbeitsverzeichnis des CVS-Verwalters überschreibt, dann gehören sie natürlich auch root. Anschließend muß root sie noch dem CVS-Verwalter übereignen (z.B. mit 'chown -R cvs:cvs <Arbeitsverzeichnis>'). Wenn root im Falle der Wiederherstellung einer Konfiguration die Dateien aus dem Arbeitverzeichnis liest, gehören sie anschließend sowieso ihm. Er muß halt nur dem CVS-Verwalter voll vertrauen können bzw. beides in unam personam sein.
(ii) Das Repository muss sich irgendwie "abgeschotten" lassen, damit nicht die ganze Konfiguration offengelegt wird. Aber dazu muss ich mich in CVS erst nochmal richtig einarbeiten.
Wenn Du das alles eh nur lokal vorhast, dann ist das hoffentlich sowieso schon der Fall - aus Gründen der allgemeinen Sicherheit und der Privatsphäre. Ansonsten läßt sich das Repository wohl kaum besondes abschotten (siehe Posting von Heiner Kuhlmann), weil ja mindestens der CVS-Verwalter Schreib- und Lesezugriff haben muß. Und wenn dann dessen Account kompromittiert wird, dann gute Nacht ... Naja, eine Möglichkeit gibt es doch: Man setzt die Gruppe für alle Repository-Dateien z.B. auf 'cvs' (chown -R :cvs <Repository>). Dann setzt man das SGID-Bit (chmod -R g+s <Repository>). Fortan erhalten alle Dateien, die in das Repository neu gebracht werden, die Gruppenzugehörigkeit 'cvs'. Nun müssen nur noch alle CVS-Berechtigten exklusiv Mitgleider der Gruppe 'cvs' werden.
Ich bin für jeden Hinweis dankbar. Das Wiederherstellen ist auch mein Hauptanliegen. Daneben möchte ich manche Dinge etwas ausführlicher kommentieren und zwar nicht direkt *in* den Konfigurationsdateien.
commit -m "Kommentar" ... Viel Spaß weiterhin, Thomas Michalka