Bug #13843 Updated: Command arguments under safe mode should not be automatically escaped

From: Date: Mon, 29 Oct 2001 21:14:34 +0000
Subject: Bug #13843 Updated: Command arguments under safe mode should not be automatically escaped
References: 1  Groups: php.dev 
Request: Send a blank email to php-dev+get-69294@lists.php.net to get a copy of this message
ID: 13843
User updated by: a.genkin@toronto.edu
Reported By: a.genkin@toronto.edu
Old Summary: Command line arguments escaped magically and out of control
Status: Open
Bug Type: Program Execution
Operating System: Unix
PHP Version: 4.0.6
New Comment:

I forgot to add that it appears that this bug is not Solaris-specific, but, rather, safe mode
specific.

Previous Comments:
------------------------------------------------------------------------

[2001-10-29 16:14:31] rasmus@php.net

Well, not being able to use shell redirection and command line args in safe-mode makes a lot of
sense.  You could trivially circumvent the safe-mode restrictions if you were allowed to do this. 
Basically safe-mode only allows system calls to very limited things.  Basically prepared scripts
placed in the safe-mode-exec-dir.  I don't see how we could allow arguments and redirects and
still maintain the point behind safe-mode.

------------------------------------------------------------------------

[2001-10-29 16:09:44] a.genkin@toronto.edu

I've looked into this further, and here's the scoop.  Under safe mode, php uses
php_escape_shell_cmd() function to escape any command passed to program execution functions.  As a
result, if I pass a command like this:

  /www/bin/foo "bar c" 2>&1

it will turn it into

  /www/bin/foo \"bar c\" 2\>\&1
I, as a PHP developer, have no control over this under safe mode.  Among other things, this means
that I cannot pass my program an argument, containing spaces, nor can I use shell redirection
machinery.

I propose a patch like below to inhibit this automatic escaping.

diff -rc php-4.0.6-orig/ext/standard/exec.c php-4.0.6/ext/standard/exec.c
*** php-4.0.6-orig/ext/standard/exec.c  Mon Apr 30 08:43:39 2001
--- php-4.0.6/ext/standard/exec.c       Mon Oct 29 15:31:06 2001
***************
*** 92,100 ****
                        *c = ' ';
                        strncat(d, c, overflow_limit);
                }
-               tmp = php_escape_shell_cmd(d);
-               efree(d);
-               d = tmp;
  #if PHP_SIGCHILD
                sig_handler = signal (SIGCHLD, SIG_DFL);
  #endif
--- 92,97 ----


------------------------------------------------------------------------

[2001-10-26 21:29:47] a.genkin@toronto.edu

4.0.6 (safe mode), Apache 1.3.20, running as server module, under Solaris 8/Sparc

When passing arguments to an executable with either exec(), system() or passthru(), special shell
characters are escaped automatically, and I have no control over it.  As a result, I am unable to
pass to the executable a paramter containing white space (such as a file name with spaces), because
I cannot surround it with quotes or backslash the spaces (the automatic escaping protects the quotes
or backslash from the shell).

Another consequence is that I cannot use shell redirection symbols (e.g. 2>&1): they get
escaped, too, and the executable receives the string "2>&1" as one of its
parameters.

If I use escapeshellarg() for each argument (as I should), the single quotes, put arround the
argument by that function, are passed over as part of the argument.  For example:

$arg = escapeshellarg("/var/www/data/foo bar.txt");
passthru( "/var/www/bin/myprog $arg" );

Produces the following output from myprog:

'/var/www/data/foo: No such file or directory
bar.txt': No such file or directory

I suspect that this bug may be specific to Solaris, since I could not reproduce the same behaviour
under identical configuration under FreeBSD.

Hoping for a fix in the upcoming release,
-- 
Arcady Genkin

------------------------------------------------------------------------



Edit this bug report at http://bugs.php.net/?id=13843&edit=1



Thread (8 messages)

« previous php.dev (#69294) next »