[Bug 10857] weirdly named files fail remotely

[samba-bugs at samba.org]

https://bugzilla.samba.org/show_bug.cgi?id=10857

--- Comment #4 from samba.org at tange.dk <samba.org at tange.dk> ---
Can we start by agreeing that rsync _could_ be aware that it is starting a
remote shell and thus _could_ quote anything that needed quoting?

Currently it clearly does not quote and puts that responsibility on the user.

My question is: Why put that responsibility on the user? Why not help the user?
Rsync knows in advance that files with weird characters will cause problems, so
why not help the user by quoting them correctly?

In other words: What situations will break if --protect-args becomes the
default?

Is rsync following the principle of least surprise by not having --protect-args
be default, and thus requiring users to write the remote file differently than
the local file?

I would say rsync is breaking that principle: I as a user assume that I can
express the remote file name the same way as the local. There might be good
reasons for breaking the POLS, but so far I have not heard any. So let me ask
again: Are there any?

I can see how the current behaviour can be abused by a malicious user if the
user knows that 'root' copies files like this:

    find . -type f -print0 | parallel -0 rsync {} remote:backup/{}

Just:

    touch 'foo`perl -e '"'"'print
map{chr}114,109,32,47,101,116,99,47,112,97,115,115,119,100'"'"'|bash`bar'

and next time root copies, /etc/passwd will vanish with NO WARNING AT ALL.

Before I discovered this behaviour, I always assumed that:

    find . -type f -print0 | parallel -0 rsync {} remote:dir/{}

would be just as safe as:

    find . -type f -print0 | parallel -0 rsync {} dir/{}

So if you still want to keep the current behaviour, I believe the man page
should be clear that giving the remote file (without --protect-args) may result
in mayhem.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.