High, high ... * saimo@bluemail.ch <saimo@bluemail.ch> schrieb am [03.07.03 10:36]: > Vielen Dank an Gerhard, fuer die ausfuehrlichen Erklaerungen. > > >So. Jetzt zu deinen exports. In deinem ersten Posting war dein > >export: > >/home/user/data/test client(ro,all_squash,anonuid=1000,anongid=1000) > > > >Du willst dieses Verzeichniss also > >-schreibgeschützt (ro), > > war ein Fehler im ersten Posting, sollte (rw) sein > > >-anonym (uid/gid als nobody) (all_squash), > >-und dieser nobody soll auf dem Server der user 1000 / gid 1000 sein > >dem Rechner client zum mounten geben. > > > >Auf dem Server muß dann das Verzeichniss die Rechte > >drwxr-x--- 1 1000 1000 > >oder > >drwxrwx--- 1 root 1000 > >haben. Weil du ja explizit auf diese id mappen willst. > >Alle SubDirs und Files müssen latürnich auch für 1000/1000 lesbar > >sein. > > habe daher die Rechte auf > drwxrwxrwx 1 1000 1000 > gesetzt > > So hat es schlussendlich auch geklappt. Noch eine kleine Frage: Was bedeutet > eigentlich die 1 (drwxrwxrwx 1 1000 1000)? Manchmal ist es ja auch > eine 2. Kann ich dir nicht genau sagen, muß aber etwas mit der Anzahl der I-Nodes, die hinter der Datei bzw. den Verzeichnissen liegen, zu tun haben. > Warum ich die userid zugewiesen habe: Auf dem Server existiert ein User (uid > 1000/gid 1000) der fuer die Backups zustaendig ist. Der User auf dem Client > soll nun seine zu sichernden Dateien auf den gemounteten Share schieben, > wo sie dann vom Backupuser zuerst (z.B. auf CD) gesichert und danach geloescht > werden. Um Probleme mit den Userrechten zu vermeiden, soll eben jeder User > unter der id des Backupusers schreiben. Ist das vernuenftig, oder sollte > man das anders loesen? Du quälst dich damit mit der klassischen Benutzerverwaltungs-Problematik herum. Dein Vorgehen hängt von verschiedenen Umständen ab, der wichtigste ist IMHO inwieweit dein Umfeld mehr privater oder geschäftlicher Natur ist. Letztlich ist die Frage: inwieweit kannst du deinen Benutzern gegen beabsichtlicher oder unbeabsichtlicher Manipulationen trauen. Und wie groß ist die Anzahl der Benutzer? Weil die "Fehler"rate bekanntlich proportional zu Benutzerrate steigt. Und: wie sensibel sind die Daten, die da gesichert werden sollen? Nur mal kurz ein paar Beispiele / Hinweise / Gedankengänge: a) Um nach deiner Methode den Usern auf den Clients überhaupt die Möglichkeit zu geben, über nfs in den mount zu schreiben, mußtest du auf dem Server den Share rwxrwxrwx machen. Jetzt kann *auf* dem Server (lokal oder per telnet/ssh/nfs) aber *jeder* beliebige Daten in diesem Verzeichnis löschen oder neue erstellen. Ganz zu schweigen vom Lesen. b) Gemeinsame Rechte (ob uid oder gid) in einem Verzeichniss bergen immer Risiken. So kann User x die Backups von User y beliebig lesen oder löschen. Als Admin sollte man solche Konstellationen wenn es geht vermeiden und den Users (und sich selbst!) die Risiken vor Augen führen. c) Wenn du wie in a) angemerkt das Backupverzeichnis sowieso für *jeden* schreib/lesbar machen *mußt*, dann könntest du dir auch den Umweg über das User-Mapping sparen, da der User 1000/1000 auf dem Server ja auch alles darf (weil jeder). Ein "rm -Rf /home/user/data/test/*" wird dir das belegen. Wer was darf ergibt sich immer aus den Berechtigungen des gerade aktuellen Verzeichnisses. Wenn du z.B. als Normal-User in einem Verzeichnis schreibberechtigung hast, kann dort auch Dateien oder Verzeichnisse löschen (rm rmdir) die z.B. root gehören. Noch ein Beispiel, wo sich für dein Backup Probleme ergeben können: Die User können nur Einzel-Dateien in dein Backup-Verzeichniss stellen. User paul vom client kopiert Datei test.txt über nfs ins Backupdir. Diese gehört jetzt (wegen anonuid/anongid) dem user 1000/1000. User paul kann diese Datei jetzt nicht mehr verändern (da die Rechte auf dem Server ja jetzt bei Standard umask 0022 rw-r--r-- sind). Er kann sie aber noch löschen (da er ja in dem Verzeichniss ja Schreib-Berechtigung hat). Genauso kann sie aber auch User peter löschen. Wenn deine User neben Einzel-Dateien auch Verzeichnisse ins Backup-Dir stellen wollen, wird es richtig haarig. User paul möchte ein Verzeichniss paultexte *mit* enthaltenen Dateien ins Backup stellen. Das klappt nicht. Warum? paul kopiert das Verzeichniss paultexte. Das Verzeichniss paultexte wird auf dem Server auch noch angelegt, wechselt aber sofort den Besitzer (eben zu 1000/1000). Und dann kann der Kopiervorgang für die Dateien aus dem Verzeichniss paultexte nicht mehr fortgesetzt werden, weil das Verzeichniss auf dem Server ja nicht mehr paul gehört und er per default auch kein Schreibrecht mehr hat. Ich würde dir raten: 1. bei einem mehr privaten Umfeld ================================ a) Du mußt die User der Clients und des Servers vereinheitlichen. Also die User, die Backups auf den Server stellen dürfen, müssen auch auf dem Server als User vorhanden sein, und zwar mit der gleichen User-ID. Dieser uids dürfen nicht überschneidend sein, also bei deinem Backup-User 1000/1000 darf es auf den Clients keinen geben, der auch die uid/gid 1000 hat. b) auf dem Server legst du eine Gruppe z.B. lbackup an. In diese Gruppe stellst du alle User die Backups anlegen dürfen plus deinen Backup-User, der das Backup ausführt. c) Du erstellst ein Verzeichniss z.B. /backups mit den Rechten drwxrwx--- 1000 lbackup Das Verzeichniss gehört also jetzt deinem Backup-User und jeder der Mitglied in der Gruppe lbackup ist, darf darin unter seiner uid schreiben. Dieses Verzeichniss exportierts du nun und zwar nur mit den Optionen (rw,root_squash). Du sparts dir also das explizite Ummappen der uid/gid auf 1000/1000. Vorteile: - die User können jetzt auch ganze Verzeichnisse ins Backup stellen - die Rechte der Dirs/Dateien bleiben erhalten (jenachdem wie du sicherst kann das beim zurückspielen wichtig sein) - die User können die Daten noch verändern. - es kann nicht mehr jeder in diesem Verzeichnis wüten. Nachteile: - immer noch kann jedes Mitglied der Gruppe lbackup jede *Datei* in /backups löschen, wenn auch nicht mehr die Unterverzeichnisse. - dein Backup-User kann /backups nicht mehr komplett leer machen. 2. sensibles Umfeld =================== Hm, diese Mail könnte jetzt noch länger werden ;-) Aber auch hier: Vereinheitlichen von uid/gid ist das A und O (NIS, map_daemon bei nfs, ugidd) Bei so einer Backup-Lösung, in dem der user die Daten explizit reinstellen muß, würde ich dann z.B. folgendes machen: a) und b) wie oben c) Ein Verzeichniss drwxr-x--- 1000 lbackup /backups d) Darin für jeden Benutzer ein eigenes Verzeichnis: drwxr-x--- peter lbackup /backups/peter oder drwx------ peter lbackup /backups/peter Vorteil: - Keiner kann mehr Daten vom anderen löschen, da ja jeder sein eigenes Verzeichniss hat. - beim modus drw------ kann auch keiner die Daten der anderen lesen. Nachteil: - auch hier kann der Backups-User das /backups nicht mehr leeren - bei drwx------ könnte er nicht einmal "backupen" Also: Ich würde mir generell überlegen, die Backups auf dem server als root auszuführen (dann klappts auch mit dem Löschen), oder zumindest nach dem Backup einen Job (cron oder script) laufen lassen, was dann als root die gesicherten Daten löscht. Und noch was: natürlich kannst du es so machen wie du es jetzt eingestellt hast. Ich wollte dir nur ein paar "Seiteneffekte" nahebringen. Du hast extra gefragt ;-) > > Gruss > Simon Gruß Gerhard
Attachment:
pgpiSXBETFk91.pgp
Description: PGP signature