On Thu, 18 Aug 2011, Grant wrote:
If I were to set up a separate user for each pushed backup and one of
the systems were compromised, only the compromised system's backups
would be accessible to the attacker (read/write unfortunately).
No. It would indeed be read/write which is a no-go for most serious backup
systems (lose the primary, and all you have left is a compromised backup,
potentially no backup at all). And another risk would be that the attacker
finds some way to elevate her privileges on the backup server due to some
but in rdiff-backup, python or something similar. In which case the entire
backup server would be compromised.
I tried to set this up today but I ran into a problem. My backup
server backs up its own files to the USB drive. If that operation is
conducted as a normal user, it can't read all of the necessary files.
If that operation is conducted as root, the backed-up files are
written as root and the remote system can't read them via rsync unless
I allow root logins.
Try doing the local operation through the localhost network ;-)
I don't think I follow (again). The backup server drops its own
important files onto the USB hard drive that is directly attached to
it. Anyway, that problem would be solved if I used your
'PermitRootLogin without-password' advice above.
You said you backup the backup server's own files to the USB drive. When
doing that with rdiff-backup running as root, the backup will also have
file permissions and ownership preserved (mostly). When you run that
rdiff-backup process as a normal user (backup side) to back up files from
root@localhost (source side), just pretending that it is a remote host,
then the backup tree will be accessible by non-root rsync user.
--
Maarten
_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki