specifying a list of files to transfer

[jw schultz]

On Tue, Jan 14, 2003 at 06:41:22PM -0800, Wayne Davison wrote:
> On Tue, Jan 14, 2003 at 04:35:40PM -0800, jw schultz wrote:
> > Absolute paths are bad news here.  Especially when dealing with an
> > rsync daemon.
> 
> Yes, this is something that needs to be dealt with for daemon mode since
> it does not appear to have been possible to specify multiple filenames
> to pull before (unlike remote-shell mode).
> 
> For non-daemon mode, the code is the same as it always was in this
> regard.  For example, this command:
> 
>     rsync -av /tmp/one /foo/two /bar/three dest:
> 
> is no different than this command:
> 
>     rsync -av --files-from=list /tmp dest:
> 
> where list contains:
> 
>     one
>     /foo/two
>     /bar/three

So in dest: you get
	one
	two
	three

and if /foo/two and /bar/three are directories they are
recoursed due to -a ?

If so that would be OK, security wise for a push.

But we don't want
	rsync -av --files-from=list source:dir /tmp
to allow pulling from source:/foo/two or source:/bar/three

Up till now rsync hasn't touched anything outside of the
paths specified on the command-line.  Changing that would
mean access to rsync via ssh would no longer be
restricted, just disabled.

Sanitizing the paths to force them to be relative on pulls
but not pushes would be too asymetrical for my liking.  I'd
rather just disallow or sanitize absolute paths.

> 
> In the patch I posted earlier, daemon mode did not work with the new
> --from-files option.  My latest patch has this fixed:
> 
>     http://www.clari.net/~wayne/rsync-files-from.patch
> 
> And it also runs the filenames through sanitize_path() in daemon mode
> (when chroot is not specified, at least -- I haven't tested a chroot
> version yet).

chroot changes the whole meaning of absolute paths anyway.

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

		Remember Cernan and Schmitt