Andrew Ferguson wrote:
Automatically repairing a failed backup will fail if you have
--restrict-update-only ... perhaps over the course of multiple backup
sessions, a malicious user could construct a source to fail in a bad
way when the repository tries to repair itself.
Or is that taking paranoia to a new level? :-)
An administrator paranoid and involved enough to be using
--restrict-update-only is assumed to be vigilant enough to pay
attention when rdiff-backup has failed (since it will error and
backtrace) and manually intervene to repair the repository.
Even so, IMO it would be better if --restrict-update-only didn't break
rdiff-backup's normal behaviour (especially the automatic fixing) - but
perhaps it is too difficult to change...
Regarding first creating new repositories, yes, I think that too will
be blocked. There was some discussion a few years ago about this:
http://savannah.nongnu.org/bugs/?16897 ... I don't remember what was
resolved. I suppose we could add os.mkdir() to the safe list.
It seems logical to me. I can see the sense in Chris's idea to restrict
sshd with ForceCommand but its applicability is quite limited if you
have to mess with it whenever you want to create a repository (or
recreate one in a new directory). I struggle to see the security danger
in allowing rdiff-backup to create a new repository?
In the thread (link we both gave) Dean was concerned about use of shared
private keys, but I don't think that is the issue; a single user from a
single machine may still want to create new repositories. Automated
setups built around rdiff-backup might want to use a really secure
system but couldn't cope with manual tweaking of sshd_config.
My 2p...
Dominic
_______________________________________________
rdiff-backup-users mailing list at [email protected]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
