restricting rsync over ssh

tim.conway at tim.conway at
Wed May 29 10:07:03 EST 2002

I don't know ssh well enough to know whether it passes parameters besides 
the ones specified in authorized_keys.  I think it passes parameters, 
though, because rsync over ssh is the basis of the IBM Content Promotion 
Tool (along with DCE/DFS), and it is TIGHTLY controlled.  It couldn't work 
if parameters like "--server -lWHogDtprRz --bwlimit=128 --force . 
/wan/pri-tools1/big1/cadappl1/hpux/iclibs/CMOS12/PcCMOS12xcorelib" (an 
example from currently running stuff on one of my systems)can't be passed. 
 You don't want to try to preparse the args.  They will change in the 

Tim Conway
tim.conway at
Philips Semiconductor - Longmont TC
1880 Industrial Circle, Suite D
Longmont, CO 80501
Available via SameTime Connect within Philips, n9hmg on AIM
perl -e 'print pack(nnnnnnnnnnnn, 
".\n" '
"There are some who call me.... Tim?"

Bennett Todd <bet at>
Sent by: rsync-admin at
05/23/2002 06:57 AM

        To:     "Brian D. Hamm" <bdhamm at>
        cc:     rsync at
(bcc: Tim Conway/LMT/SC/PHILIPS)
        Subject:        Re: restricting rsync over ssh

On Wed, May 22, 2002 at 10:01:27PM -0400, Brian D. Hamm wrote:
> The --server --sender options left me a little confused. I understand
> what they stand for but these options are not in the help and they don't
> appear to be variables.

Yes indeed, as I tried to indicate, rsync has a private protocol, based on 
use of undocumented cmdline options, for talking to itself in various

I believe it's pretty near obligatory to presume that such a private 
is kept undocumented so as to reserve the right to the rsync developers to
change it without notice in future versions; that's why I cautioned that 
this sort of restriction puts you in the position of perhaps having to 
it when another release comes around, and having to do some guesswork if 
want a wrapper to parse the cmdline to provide restricted flexibility in
permitted invocations.

What say, rsync developers, any chance that the details of this cmdline
invocation --- the one rsync runs over rsh or ssh or whatever to establish
it's connection --- could be formally documented? Combined with such 
tricks as
the authorized_keys command="..." plus SSH_ORIGINAL_COMMAND this would 
us a documented way to provide fine-grained restrictions over what is 
I really like doing this; e.g. I've set up backup facilities where the 
that's being backed up can _only_ update its own mirror area, and the 
of previous contents (as well as everything else on the system) are
inaccessible to it.


To unsubscribe or change options:
Before posting, read:

More information about the rsync mailing list