restricting rsync over ssh on the server side.

[jw schultz]

On Sun, Jan 05, 2003 at 07:50:57PM -0600, Rob Browning wrote:
> jw schultz <jw at pegasys.ws> 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
exit.

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw at pegasys.ws

		Remember Cernan and Schmitt