Re: bin/31107 (scp can't handle remote file names with '(' in them)

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

The following reply was made to PR bin/31107; it has been noted by GNATS.

From: Manuel Bouyer <bouyer%antioche.eu.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: gnats-admin%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost, 
dillo%NetBSD.org@localhost
Subject: Re: bin/31107 (scp can't handle remote file names with '(' in them)
Date: Tue, 29 Apr 2008 21:47:23 +0200

 On Mon, Apr 28, 2008 at 04:50:02PM +0000, Dieter Baron wrote:
 > The following reply was made to PR bin/31107; it has been noted by GNATS.
 > 
 > From: Dieter Baron <dillo%danbala.tuwien.ac.at@localhost>
 > To: gnats-bugs%NetBSD.org@localhost
 > Cc: 
 > Subject: Re: bin/31107 (scp can't handle remote file names with '(' in them)
 > Date: Mon, 28 Apr 2008 18:46:39 +0200
 > 
 >  On Mon, Apr 28, 2008 at 02:54:24AM +0000, dholland%NetBSD.org@localhost 
 > wrote:
 >  > Synopsis: scp can't handle remote file names with '(' in them
 >  > 
 >  > When I do
 >  >    scp otherhost:\(* .
 >  > the local shell expands the *.
 >  
 >    Expansion of * is a non-issue here, unless you really have a file
 >  matching ``otherhost:\(*'': If a glob does not match anything, the
 >  shell leaves it unexpanded.
 
 It depends which shell. 
 
 >  
 >  > If I write
 >  >    scp otherhost:'\(*' .
 >  > it works perfectly as I would expect - it fetches all remote files that
 >  > match the glob \(*.
 >  
 >    Indeed.  Note, however, that you quoted the ``('' twice: once inside
 >  single quotes, and once with a backslash.  The local shell eats the
 >  quotes, the remote shell the backslash.
 >  
 >  > What behavior were you expecting/trying to achieve?
 >  
 >    I would expect
 >      scp otherhost:\(\* .
 >    to work, and not give the following error:
 >  
 >  bash: -c: line 0: syntax error near unexpected token `('
 >  bash: -c: line 0: `scp -f (*'
 >  
 >    This makes me think of nasty surprises given strange names like
 >  ``foo; rm -rf /''.  One might even call it an exploitable security
 >  hole.
 >  
 >  > I would expect that any quoting at the other end that would protect
 >  > parens would also inhibit remote wildcard expansion, which would be
 >  > highly undesirable.
 >  
 >    1) We could escape every meta-character (including globs) and have
 >       scp -f expand them (via glob(3) or similar).
 >  
 >    2) We could escape shell meta-characters that are not glob
 >       meta-characters (like `(', '&', '>', ...) with backslashes.
 
 The list of meta-characters is shell-dependant, isn't it ?
 
 >  
 >    At the very least, we should document that shell meta-characters
 >  have to be escaped twice.  (On a related note, we should also document
 >  that a file with `:' in its name has to be copied as ./file:name.)
 
 what should, eventually, be documented is that the remote file name is
 passed to the remove shell. How they have to be expanded really depends
 on the remove shell. You could use a remote shell that doesn't expand
 any metacharacters at all.
 
 -- 
 Manuel Bouyer <bouyer%antioche.eu.org@localhost>
      NetBSD: 26 ans d'experience feront toujours la difference
 --