-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

At some point hitherto, John Chambers hath spake thusly:
> Derek D. Martin wrote:
> | As I mentioned I would, I wrote a quick dummy shell to allow scp and
> | sftp, but not anything else.  It has a minor problem and a major
> | problem (that I know about), but still should work in most cases for
> | most people.  The minor problem was that in a few cases, I was too
> | lazy to check return codes.  That's a 10-minute fix that I'm still too
> | lazy to make.  :) The major problem is that if one of the arguments to
> | scp is a filename that contains a (quoted) space, the spaces will be
> | treated as argument delimitors.  I didn't make much effort to do a
> | whole lot of processing on the command line, so any space that appears
> | in argv[2] will be treated as an argument delimitor for the command
> | which is exec'd.
> 
> So which language did you use?  There may be a simple solution.  In a

Thanks for your suggestions John.

I wrote it in C (code was attached)...  Scripting languages are often
a bad choice for writing such things as restricted shells, because
even though they often provide easier manipulation of strings, they
also often provide ways to break out of the script or ways to
manipulate the environment so that the user can do things they're not
supposed to be able to do.

The solution in C isn't so hard, just somewhat tedious to code by
comparison to some other languages...

> lot  of  them,  just surrounding the arg in double quote ("$argv[2]")
> will protect the spaces and pass the string to  the  program  as  one
> argument.   Interpreters  like  perl and tcl also have simple ways of
> handling this problem.

This isn't really all that helpful...  What's going on here is the scp
program (for example) passes the shell on the remote end a command,
via the -c option to the shell.  The argument that follows the -c is
intended to be a complete command line, but it's all one argument to the shell.
I.E. it might look like this:

  -c scp -t zippy

However, this is deceptive.  The -c is one argument, and the string
"scp -t zippy" is the next argument (argv[2] to the shell).  To
complicate matters, the name of the file you're trying to copy might
have a space in it, so you'd have to quote the filename in one of
several ways which would be acceptable to your shell.  The most common
would be to enclose it in quotes.  So you'd end up with something like:

  argv[1]: -c
  argv[2]: scp -t "zippy's file"

You need to handle the quoted space, as well as strip the quotes.
Worst part of it is there are several ways to quote the filename,
using only bourne-compatible shell semantics.  It could be represented
legitimately by:

  "zippy's file"
  zippy\'s\ file
  'zippy\'s file'

...and probably half a dozen other combinations, including using octal
notation.  This isn't really all that hard to code for, but it's
fairly tedious.  Worse problems are if you want to scp a file which
has really funky characters in the file name, such as say, ^b.  I
probably would be disinclined to account for such nonsense, as it's
far too tedious, and I personally think using such filenames is just
plain stupid.  But obviously one'd have to document what one allows
and doesn't...


- -- 
Derek Martin               ddm@pizzashack.org    
- ---------------------------------------------
I prefer mail encrypted with PGP/GPG!
GnuPG Key ID: 0x81CFE75D
Retrieve my public key at http://pgp.mit.edu
Learn more about it at http://www.gnupg.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9TYEMdjdlQoHP510RAkoOAJ4yWozK0rHtUCmy5V4OQ7ylMCWyZgCfa/I5
bvi1UzIzCPxR4XCF5qhbUA4=
=KIHY
-----END PGP SIGNATURE-----