The Samba-Bugzilla – Bug 5607
Add a way to elide the client's use of -e to the server
Last modified: 2008-07-26 10:01:01 UTC
Server: rsync version 2.6.9 protocol version 29
Client: rsync version 3.0.2 protocol version 30
rsync -aiHOvvvvvvvv --no-implied-dirs -e ssh --filter '+ files/**/.htaccess' --filter '+ */' --filter '- files/**' --delete-after --max-delete 8 /home/abc/def/www/_ghi/ firstname.lastname@example.org:/home/abc12345/public_html
Before update of client (mirror source) from 2.6.9 to 3.0.2:
cmd=ssh cmd=-l cmd=abc12345 cmd=homepages.xyz.de cmd=rsync cmd=--server cmd=-vvvvvlOHogDtpr cmd=--log-format=%i cmd=--max-delete=8 cmd=--delete cmd=--delete-after cmd=. cmd=/home/abc12345/public_html
opening connection using ssh -l abc12345 homepages.xyz.de rsync --server -vvvvvlOHogDtpr "--log-format=%i" --max-delete=8 --delete --delete-after . /home/abc12345/public_html
(Client) Protocol versions: remote=29, negotiated=29
After update of client:
cmd=ssh cmd=-l cmd=abc12345 cmd=homepages.xyz.de cmd=rsync cmd=--server cmd=-vvvvvvvvlOHogDtpre.i cmd=--log-format=%i cmd=--max-delete=8 cmd=--delete-after cmd=. cmd=/home/hg14363/public_html
opening connection using: ssh -l abc12345 homepages.xyz.de rsync --server -vvvvvvvvlOHogDtpre.i "--log-format=%i" --max-delete=8 --delete-after . /home/abc12345/public_html
note: iconv_open("ISO-8859-15", "ISO-8859-15") succeeded.
insecure -e option not allowed.
This account is restricted by rssh.
Allowed commands: scp sftp rsync
If you believe this is in error, please contact your system administrator.
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
Apparently the 2.6.9 server gets confused by the "e." option in cmd. After commenting out addition of "e." in options.c:server_options() everythings works as before.
Note this message:
> insecure -e option not allowed.
> This account is restricted by rssh.
I.e., the error is coming not from the rsync server but from a restricted-rsync wrapper that rejects the -e option. That option is perfectly safe for rsync servers, so the wrapper should be updated to allow it. See this thread:
As the thread that Matt pointed out mentions, -e is completely safe as long as the command has the --server option. The rrsync script requires it to be the first option on the command-line, which is an easy check and works for normal cases (and can even work with someone who is passing --rsync-path="rsync --options" as long as the user specifies their own --server option as the first option).
One thing that rsync 3 could be improved to do is to omit that "e..." sequence if --protocol=29 is specified. That would at least make it easy for a user to communicate with an overly restrictive server that won't update their software.
Created attachment 3403 [details]
Make --protocol=29 option disable sending of -e... to the server
With this patch, you can specify --protocol=29 to and rsync 3 client and won't send the -e... flags. Thoughts?
(In reply to comment #3)
> Created an attachment (id=3403) 
> Make --protocol=29 option disable sending of -e... to the server
> With this patch, you can specify --protocol=29 to and rsync 3 client and won't
> send the -e... flags. Thoughts?
This seems to be a feasible option when the user is not allowed to update the server / wrapper.
Since the -e flags to the server are only used in protocol 30, attaching this side effect to the --protocol=29 flag is a safe way to go.
This change is now in the git repository.