specifying a list of files to transfer

[Lee Eakin]

Please pardon my butting in again.  I am not a developer, but I am very
interested in this option because I've need it in the past and had to work
around the lack of it with include/exclude options (I wanted to sync only
a few files from a large directory, and needed it to work via the daemon
for anonymous access).  I also maintain the perl wrapper File::Rsync so I
do my best to understand all of the options so I can handle them properly
in the perl module.

---begin quoted text---
> From: Wayne Davison <wayned at users.sourceforge.net>
> Date: Tue, 14 Jan 2003 19:39:49 -0800
> 
> 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.
> 

Yes, people do restrict args via ssh key restrictions.  I have done this
myself on many occasions.  The environment variable SSH_ORIGINAL_COMMAND
is passed to the actual command called from the command= key option so I
write a small script to parse thru the variable checking each arg making
sure they are what I expect (and possibly modifying them).  I also check
pathnames to make sure they all fit my restrictions.  I then either exec
rsync, or email the offending command to root if I find an exception
(the mail also makes debugging easier).

I assume the remote end will get the expanded contents of files-from so
ssh command parsing would still work properly.

> > 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.

If you try to pull a full pathname from a daemon 'rsync remote::/foo' it
errors out with:

  ERROR: The remote path must start with a module name not a /

so any sanitize code could first make sure all pathnames begin with a valid
module and then make sure the file or dir is really inside that module.

---end quoted text---

-- 
    Lee Eakin - leakin at ti.com - Internet/Naming Services, Texas Instruments
 
LAWS OF COMPUTER PROGRAMMING:
II. Any given program costs more and takes longer.