restricting rsync over ssh on the server side.

jw schultz jw at
Mon Jan 6 02:27:00 EST 2003

On Sun, Jan 05, 2003 at 07:50:57PM -0600, Rob Browning wrote:
> jw schultz <jw at> writes:
> > I'm just wondering what you are suggesting be added to rsync
> > that couldn't be done by the wrapper you already need.
> >
> > You can already restrict --delete and check the paths rsync
> > will operate on to ensure they are within the designated
> > trees.  As it is rsync won't read or write anything
> > outside of a paths specified on the command line.
> Hmm.  Well with rsync I was under the perhaps mistaken impression that
> the invocation on the destination side when using ssh wasn't well
> documented, and I wasn't sure it would be amenable to
> parsing/rearrangement via a wrapper.
> However, if that's not the case, and if the rsync server-side
> invocation were just documented well and if it was fairly easy to
> parse the arguments and adjust them safely and correctly, then that,
> along with command="foo" and SSH_ORIGINAL_COMMAND should make a
> suitable restriction wrapper possible.
> I just didn't want to do something like that if it wasn't an approach
> the upstream developers wanted to accomodate long-term.  It seems like
> it would be too easy for upstream changes to introduce new options
> that might open up security holes unless the developers were keeping
> the ssh wrapper usage in mind, or unless the wrapper were maintained
> as a part of rsync.

For the most part there shouldn't be much of a problem.
What you are talking about doing is erroring out if the
path(s) are out of bounds, and either adding/removing
options or erroring if they are missing/present.

You could just take the SSH_ORIGINAL_COMMAND and check to
see if it conforms to requirements.  If it does, run it.  If
it doesn't, kick out an (informative) error message and

	J.W. Schultz            Pegasystems Technologies
	email address:		jw at

		Remember Cernan and Schmitt

More information about the rsync mailing list