On Thu, Feb 19, 2009 at 02:19:42PM -0800, Brian Warner wrote: > the same weak checksums), and put A1 on the destination machine and A2 > on the source, then 'rsync ./A2 remote:A1' would fail to properly > replace A1 with A2. But they're both your own files anyways.
Not necessarily: I can think of many scenarios where it might be advantageous to ensure that rsync (or more generally, the system backup) would skip backing up a new version of a file. Such situations can occur anytime the creator of the file has interests that do not align with the person performing the backup operation. For instance, say I wish to hide a logic bomb on a corporate server, that six months after I left the company would activate and perform some unfriendly action. However I don't want to leave evidence behind, and the machine in question is backed up nightly to an incorruptible offsite system. If I simply uploaded the malicious executable, after it triggered one could go back and find said malicious code in the backups, providing forensic evidence that could be used against me. So instead I could prepare two files, the logic bomb executable plus an innocouous file which rsync would consider to be identical. Since most binary formats (eg ELF binary files, Office documents) are quite flexible, I could perhaps even create my dummy file to be something meaningful. Then I place the innocouous version where it will be backed up, after which I replace it with the malicious version. Then numerous backup operations would occur, and (assuming the malicious version deleted or replaced itself after triggering) leave no evidence behind, without having to corrupt the backup server or process itself. -Jack _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
