* Maarten J H van den Berg wrote on Fri, Sep 07, 2001 at 12:44 +0200:
On Friday 31 August 2001 23:21, you wrote:
Again a late reply... here goes
No problem, I'm glad that you found time for this article!
* Maarten J H van den Berg wrote on Mon, Aug 06, 2001 at 18:29 +0200: [..] But back to the issue; you say rsync should filter paths and so on, I beg to differ (Caveat: If I'm not overlooking something) Look at my config. This is what the client commandline looks like:
rsync -e ssh -ogptLrcv --stats --partial --exclude=logs/ --safe-links /etc/foobar root@www.xxx.yyy.zzz:/home/backups/Host-AAA/
BTW, why not "-a" == "-rlptg". Differs on links to your flags. If I understand correctly, -L "follows" the links and dumps the files. Bad on /etc/rc.d/rc2.d and friends.
And this is the server-side exerpt from authorized_keys:
command="rsync --server -vLogtprc --partial --safe-links . /home/backups/Host-AAA/",no-port-forwarding,no-X11-forwarding,no-agent-forwarding 1024 35 123456789....................123456789 root@aaa.bbb.ccc.ddd
Okay, now try to run a doctored backupcommand like:
rsync -e ssh -ogptLrcv --stats --partial --exclude=logs/ --safe-links /etc/foobar root@www.xxx.yyy.zzz:/home/backups/Host-AAA/../../../
[...looks safe...]
So you see, as I wrote earlier, the SERVER IS ENFORCING the command which the client tries to run. (Again, unless I made a mistake that is.)
Well, looks nice. I don't know why, but I though to write some wrapper which allows /home/backups/whatever/*, I mean that allows "deeper" definitions - but now I think you're right and this shouldn't be neccesary. If you specify /../ at the end, SSH shouldn't even start rsync, so this should be safe. But the question is, if the rsync protocol is internally safe. scp hat such a bug, it created the file requested by the client even if outside it's destination IIRC. So it may be possible to create a modified rsync client, which delivers ordinary files plus a new /root/.ssh/authorized_keys or whatever. But I think it would take some time to analyse the rsync sources.
If you can show me a commandline that does indeed break out of the target dir, I'd be VERY interested to know, needless to say.
Well, I think it's required to patch the rsync client. I don't know if the server checks the path of the files, I never looked at the rsync protocol. Maybe it's possible to specify a list like /etc/foobar --> /home/backups/Host-AAA/foobar /etc/foobar2 --> /home/backups/Host-AAA/foobar2 /etc/foobar3 --> /etc/foobar3 /etc/foobar4 --> /home/backups/Host-AAA/foobar4 In such a case, the server should reject foobar3 since it's outside the destination. Or imagine: /etc/foobar2 --> /home/backups/Host-AAA/foobar2 /etc/foobar3 --> /home/backups/Host-AAA/../../../etc/foobar3 or: /etc/foobar2 --> /home/backups/Host-AAA/foobar2 /../../../etc/foobar3 --> /home/backups/Host-AAA/../../../etc/foobar3 usually rsync wouldn't generate such lists of course, but it may be possible to patch it in such a way (on client side). But it's difficult to check it in a few minutes, since the patch isn't trivial I think. Are there any experiences or audits?
I commented on the use of tarballs above. It wasn't useable for me at the time. However, If you CAN, this is indeed a safer option.
You're right, rsync has nice advantages, it's fast and a restore of a single file (i.e. deleted by accident) is much more easy. A second point: you decided that the clients "pushes" it's files to the backupserver. I decided that the backupserver "polls" the files from the client. I though, since it better since: - the load of the backupserver is constant on backups, since all clients can be polled after the other (no "concurrent" backups) - A single point for "logging" (I see if a host was down on backup time. A host which is down won't mail - you won't see any error message). - root access via key needed. I deciced to put the client keys on a key disc, told ssh to use a key which is a symlink to automounted /misc/floppy. Once a week, i.e. saturday night, an operator inserts the disk with the keys into the backup server, and not a key with a single key to each backupclient What are your reasons for doing client "push"? oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.