[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Ausführungsrechte



Hallo Peter!

* Peter Jordan <usernetwork@gmx.info> (Fri, 06 Jul 2007 11:47:27 +0200):
> 
> Fabian Pietsch, 07/06/07 10:20:
> > 
> > Wofür brauchen die Benutzer denn root-Rechte für rsync, also, was
> > sollen/werden sie dann tun?
> > 
> 
> Ich habe einen Backupserver, auf dem ich Daten von verschieden
> Servern/PCs mittels rsync und ssh sichere. Da dieses Skript voll
> automitsch abläuft, läuft der Login mittels des pub-key verfahrens; dass
> ich per ssh kein root login erlaube versteht sich von selbst.
> 
> rsync benötigt jedoch für das Anlegen und das ggf. erforderliche Löschen
> der Daten Root-Rechte, ebenso wie andere erforderliche Programme
> (cryptsetup, rm, mount, umount, wipe, touch, mkdir usw). Für jeden zu
> sichernden Server habe ich einen eigenen Nutzer (zB thinkpad), der in
> der Gruppe backupuser ist und somit die erforderlichen Rechte bekommt.
> 
> Ich hoffe das war verständlich.
> 
> Viele Grüße,
> 
> PeterJordan

Man muss die Daten auf dem Backup-Server ja nicht unbedingt denselben
Benutzern wie auf den Backup-Clients gehören lassen(, i.d.R. sind
ohnehin nicht überall genau dieselben Nutzer vorhanden). Außerdem ist
von den Backup-Clients ferngesteuertes cryptsetup ohne die Schlüssel auf
dem Backup-Server zu speichern (Ich lese da heraus, dass du das so
machst.) auch nicht viel sicherer als sie dort zu speichern, da sie bei
Kompromittierung des Backup-Servers auch einfach beim nächsten Backup
abgehört werden können.


Hast du dir mal rdiff-backup angeschaut? Das sollte auf dem
Backup-Server speichern (und später auf dem Backup-Client
wiederherstellen) können, wem welche Datei gehörte und welche Rechte er
drauf hatte, auch wenn auf dem Backup-Server alle Daten eines
Backup-Clients demselben Benutzer gehören. (Außerdem hast du dann nicht
"nur" einen mirror, sondern auch binary diffs zu alten Versionen, ohne
viel Platzverschwendung. Solltest du rsync nicht zum effizienten
Aktualisieren von mirror backups verwenden, sondern einfach nur zum
wiederholten Komplett-Übertragen mit regelmäßiger Komplettlöschung alter
Backups, siehe dar.)


Außerdem gibt es dar (Disk ARchive); damit kann man die Daten in ein
einzelnes file pro backup sichern, in welchem auch die Nutzer- und
Rechte-Informationen vorliegen. Es kann inkrementelle Backups, ohne auf
die alten Backups direkt zugreifen zu müssen. (Man kann deren Kataloge
extrahieren, auch direkt bei ihrer Erstellung.) Außerdem kann es nativ
(also ohne z.B. tar durch gpg zu pipen o.ä.) verschlüsseln, was dann
Backup-Client-seitig geschieht und auch bei Kompromittierung des
Backup-Servers zumindest nicht die Daten aller Backup-Clients lesbar
macht.

Im Gegensatz zu tar kann man durch das Vorhandensein der Kataloge auch
direkt einzelne Dateien extrahieren, ohne möglw. das ganze Archiv
lesen/entschlüsseln zu müssen. Sollte also auch keine zu große
Einschränkung ggü. Datei-für-Datei in ein Dateisystem sichern bedeuten.
Zuguterletzt kann dar bestehende Backups nahezu beliebig in Teildateien
fester Größe aufsplitten / Teildateien zusammenfügen / neusplitten, ohne
ent- und wieder verschlüsseln zu müssen. Das kann hilfreich sein, falls
man (zumindest full backups einmal im Monat oder so?) auf entfernbare
Datenträger schreiben will.


Mit rdiff-backup oder dar solltest du ganz ohne root-Rechte für die
Backup-Clients auf dem Backup-Server auskommen.

HTH
Fabian


-- 
Fabian "zzz" Pietsch - http://zzz.arara.de/



Reply to: