restricting rsync over ssh on the server side.

[Rob Browning]

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.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4