specifying a list of files to transfer

[Lee Eakin]

> From: jw schultz <jw at pegasys.ws>
> Date: Tue, 14 Jan 2003 20:33:46 -0800
> 
> On Tue, Jan 14, 2003 at 10:15:42PM -0600, Lee Eakin wrote:
> > ---begin quoted text---
> > > From: jw schultz <jw at pegasys.ws>
> > > Date: Tue, 14 Jan 2003 20:07:58 -0800
> > > 
> > > 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.
> > > 
> > 
> > Oh, I see now.  Yes that could be a serious hole.  If the remote command
> > included an option (maybe a dummy --files-from) then the ssh wrapper could
> > at least abort and notify when it sees it.
> 
> If you look at Wayne's description of the patch the remote
> command does have a --files-from=- on it's command-line.
> However it would be a shame to disable that performance
> enhancing facility if we just need sanitize the contents of
> the file-from list and require that it only specify paths
> relative to the source and dest trees.
> 
> I suppose we could allow an option that would permit
> unsanitized paths.
> 

I would agree.  If the paths are known to be relative (forced to be by the
rsync running where the ssh restriction is) then (assuming the wrapper's
intent is to allow access to the whole sub-tree) it could allow the
files-from option.  If you only want to allow access to specific files,
then it would still have to disallow the option.

I can think of one possible way for the wrapper to find out what files are
being requested, but don't know enough about the interconnect between the
2 rsyncs to know if it would break it (probably).  If the wrapper could
run a modified version of the original command without a destination it
would print out a list of the files (remember that if you do not give a
destination it prints something similar to 'ls -l' with includes and
excludes applied) then it could walk the output and verify all the paths.
If it passed inspection, it could call the real command passing the file
list to stdin itself.  It would have to attach stdout and stderr properly,
and may even have to act as a pass-thru for further data coming on stdin.
It would be complicated, but might be possible if the dummy (no destination
run) did not close off the connection after reading the file list, and/or
the handshaking was clearly documented so non-developers could understand
it.

I only throw this idea out because I would really like files-from to work
even in a restricted-access mode.  It is a BIG win over parsing a large dir
for includes/excludes.

-- 
    Lee Eakin - leakin at dfw.nostrum.com
 
Murphy's Military Laws:
6. The buddy system is essential to your survival;
   it gives the enemy somebody else to shoot at.