NetBSD Problem Report #31107

From dillo@danbala.tuwien.ac.at  Wed Aug 31 09:19:06 2005
Return-Path: <dillo@danbala.tuwien.ac.at>
Received: from danbala.tuwien.ac.at (danbala.ifoer.tuwien.ac.at [128.130.168.64])
	by narn.netbsd.org (Postfix) with ESMTP id A619A63B8A7
	for <gnats-bugs@gnats.NetBSD.org>; Wed, 31 Aug 2005 09:19:05 +0000 (UTC)
Message-Id: <20050831091904.4B34613A77A@danbala.tuwien.ac.at>
Date: Wed, 31 Aug 2005 11:19:04 +0200 (CEST)
From: dillo@NetBSD.org
Reply-To: dillo@NetBSD.org
To: gnats-bugs@netbsd.org
Subject: scp can't handle remote file names with '(' in them
X-Send-Pr-Version: 3.95

>Number:         31107
>Notify-List:    gson@gson.org
>Category:       bin
>Synopsis:       scp can't handle remote file names with '(' in them
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    bin-bug-people
>State:          closed
>Class:          doc-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Aug 31 09:20:00 +0000 2005
>Closed-Date:    Sat Dec 31 03:53:23 +0000 2022
>Last-Modified:  Sat Dec 31 03:53:23 +0000 2022
>Originator:     Dieter Baron
>Release:        NetBSD 2.0.2
>Organization:

>Environment:


System: NetBSD wintermute 2.0.2 NetBSD 2.0.2 (WINTERMUTE) #0: Mon May 16 12:15:09 MEST 2005 root@wintermute:/usr/src/sys/arch/i386/compile/WINTERMUTE i386
Architecture: i386
Machine: i386
>Description:
Trying to copy a file with '(' in it's name from a remote host fails:
	$ scp gateway:\(* .
	bash: -c: line 0: syntax error near unexpected token `('
	bash: -c: line 0: `scp -f (*'

quoting the '\' helps:
	$ scp gateway:\\\(* .
	(foo)                                26%  712KB  29.3KB/s   01:06 ETA
but this should not be necessary (and is not documented as required either).

>How-To-Repeat:
	scp localhost:\(* .
>Fix:
	correctly quote the file name passed to scp on the remote end.

>Release-Note:

>Audit-Trail:

State-Changed-From-To: open->feedback
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Mon, 28 Apr 2008 02:54:23 +0000
State-Changed-Why:
When I do
   scp otherhost:\(* .
the local shell expands the *. If I write
   scp otherhost:'\(*' .
it works perfectly as I would expect - it fetches all remote files that
match the glob \(*. What behavior were you expecting/trying to achieve?
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.


From: Dieter Baron <dillo@danbala.tuwien.ac.at>
To: gnats-bugs@NetBSD.org
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 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.

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

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

 					yours,
 					dillo

From: Manuel Bouyer <bouyer@antioche.eu.org>
To: gnats-bugs@NetBSD.org
Cc: gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org, dillo@NetBSD.org
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>
 > To: gnats-bugs@NetBSD.org
 > 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 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>
      NetBSD: 26 ans d'experience feront toujours la difference
 --

State-Changed-From-To: feedback->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Mon, 25 Aug 2008 01:31:04 +0000
State-Changed-Why:
Feedback was received. Docs need to be clarified.


State-Changed-From-To: open->closed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sat, 31 Dec 2022 03:53:23 +0000
State-Changed-Why:
The current scp docs discuss this briefly. I'm not sure I'd consider it
entirely adequate, but it also doesn't seem worth arguing about it with
upstream.


>Unformatted:

Home	PR Database Search