specifying a list of files to transfer

[jw schultz]

On Tue, Jan 14, 2003 at 07:39:49PM -0800, Wayne Davison wrote:
> On Tue, Jan 14, 2003 at 07:02:58PM -0800, jw schultz wrote:
> > 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.
> 
> Are you saying that some people have special ssh scripts that check
> and/or tweak the file names on the command-line to ensure they fall with
> certain bounds when running rsync commands?  I.e., if someone ran this
> command:
> 
>     rsync -av -e ssh "source:dir /foo/two /bar/three" /tmp
> 
> the remote ssh setup would handle the presence of the extra "/foo/two",
> "/bar/three" args?  If so, I hadn't realized that people were limiting
> ssh access by more than the traditional user/group/permissions access.

I don't know if they can handle correctly multiple source
paths on the command line but there are certainly people
using the command= option in authorized_keys to invoke
special scripts to check and/or tweak the rsync command line
restrict rsync to pre-aproved paths.

> > Sanitizing the paths to force them to be relative on pulls
> > but not pushes would be too asymetrical for my liking.
> 
> I agree that if we find that we want to sanitize the paths in some cases
> that we should just make it the default for files-from -- i.e. make it
> where nothing can get beyond the root dir specified on the command-line.
> 
> > I'd rather just disallow or sanitize absolute paths.
> 
> Note that it's more pervasive than just absolute paths, since someone
> can use args like "../../../etc/password" or "good_dir/../../bad_dir"
> (all of which the sanitize_path() call handles).

Yes, the relative ../../... paths slipped my mind but that
is a concern as well.

I'm aware that restricting --files-from to having relative
paths is somewhat limiting but i think it may be the better
approach.  You can always do

	rsync --files-from=list / remote:/

If you need to.

I haven't had time yet to closely examine or try it but i
have two questions:

with the -r or -a options does this recourse on
directories in the --files-from list?

What happens when there are implied directories that are
missing on the destination?  For example
	rsync -a --files-from=list src dest
with the list having
	foo/bar/one
will dest/foo and dest/foo/bar be created with the source
directory attributes if they don't exist; will it fail; or
will the missing implied directories be created with umask
perms?

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

		Remember Cernan and Schmitt