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