specifying a list of files to transfer

jw schultz jw at pegasys.ws
Wed Jan 15 04:09:01 EST 2003


On Tue, Jan 14, 2003 at 10:01:47PM -0600, Lee Eakin wrote:
> 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.

Nope.  The files-from contents needs to passed on stdin otherwise
we would hit command-line length limits.  That is why i'm
stressing the fact that allowing paths not within the source
or destination trees specified on the command-line would
bypass your ssh command= wrapper restrictions.

> 
> > > 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.
> -- 
> To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
> Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html

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

		Remember Cernan and Schmitt



More information about the rsync mailing list