rsync - Oct 2009 - Limiting remote operations to a particular directory, and not above ?

I am tasked with pointing rsync transfers to valuable, live systems.

The requirements include that this rsync job be run as root (rsync over ssh to
the destination, as root) and that the --delete option be used.

The last piece is, the _remote_ destinations are not fixed - they are generated
from a database and fed into my rsync script.

So, of course the worry is that one of these destination paths, to be syned to
the remote server, will be malformed or broken in some way, and I end up doing
a:

rsync --delete

against '/' or god knows what.  I could conceivably blow away the entire
remote filesystem with a badly formed input.

-----

So, on my end, I have done extremely robust bounds checking on those input
paths.  Really, really over the top - if you saw it you'd laugh.  But the
problem is, I still lie awake at night wondering...  did I think of everything ?
What if someone edits the script in a seemingly benign way, but breaks the
insanely strict bounds checking ?

What would really make me feel better is if I could somehow tell rsync:

"don't operate at all below /this/point/in/remote/filesystem"  No
matter what.

That way, no matter how broken the input was, the worst that could happen is
that I would --delete things at
/this/point/in/remote/filesystem/somewhere/deeper/or/whatever.

I don't see an option like this.  Does anyone have any pointers ?


(I have thought of chrooting a different sshd on the remote, but I'd really,
really, like to keep the complexity and configuration on the sending end and
just leave these very simple remote systems alone)

On Wed, 2009-10-21 at 13:40 -0700, George Sanders wrote:
> I am tasked with pointing rsync transfers to valuable, live systems.
> 
> The requirements include that this rsync job be run as root (rsync
> over ssh to the destination, as root) and that the --delete option be
> used.
> What would really make me feel better is if I could somehow tell
> rsync:
> 
> "don't operate at all below /this/point/in/remote/filesystem"
No
> matter what.
An rsync daemon is the right tool to ensure this, without a doubt.
> (I have thought of chrooting a different sshd on the remote, but I'd
> really, really, like to keep the complexity and configuration on the
> sending end and just leave these very simple remote systems alone)
If you don't want to configure the receivers in advance, your script can
invoke a single-use daemon with the configuration data passed on the
command line, like so (bash):

function quote_args {
	apos="'"
	bs=\\
	# Escape existing single quotes.
	set -- "${@//$apos/$apos$bs$apos$apos}"
	# Wrap each arg in single quotes.
	set -- "${@/#/$apos}"
	set -- "${@/%/$apos}"
	# Join the args with spaces.
	echo "$*"
}

CONFIG='
[module]
	path = /this/point/in/remote/filesystem
	uid = root
	gid = root
	read only = false
'

rsync -e ssh --rsync-path="rsync --config=<(echo $(quote_args
"$CONFIG"))" \
	OPTIONS SRC ... rsync://HOST/module

Yes, this is pretty crazy, but it accomplishes what you want.

-- 
Matt