Will someone please address this security issue. It's huge!

Tried:
 
 php_admin_value disable_functions "system,exec"

On a per directory basis?

You can't use disable_functions on a per-dir basis because it is impossible to implement in an efficient manner.

safe_mode already addresses this issue with its safe_mode_exec() dir.  I am sorry if you feel this is too restrictive, but there is simply no way to make open_basedir restrictions apply to arbitrary scripts a user might run.  Use safe-mode or set up a jailed configuration with individual instances of Apache listening on separate ports with a reverse proxy out front directing port 80 requests to the appropriate internal port.

Why is it so impossible?  Just allow certain functions like 
the ticker command to be turned off for a virtual server. I 
got into a shared server yesterday that turned off the 
system and the exec commands system wide, but I was still 
able to execute the ticker command.  That?s bad.  There has 
to be a way to prohibit these commands for virtual 
directories.

You can't use disable_functions on a per-dir basis because 
it is
impossible to implement in an efficient manner.

You should make this work:
php_admin_value disable_functions "system,exec,`"

Try this in safe mode:
$test=`ls -la`;
print $test;

If you cold make the open_basedir command work with the 
system,exec and ticker commands that would sove the problem 
too.

I just don?t want people to see anything past their root 
directories, while I need full access to call binaries.

Thanks 
Greg

I will repeat Rasmus' statement: It is impossible to implement this in a nice and straitforward way, feel free to come up with a patch on your own. The backticks as we call them are NOT functions, but properties of the PHP language, you can turn this off with safe_mode.

How about a virtual chroot, if you will, within php.ini and httpd.conf (needed per vhost). I hacked suexec for perl scripts to *actually* chroot to the vhosts directory tree. Needless to say this meant hardlinking required libs and executables to the vhosts directory tree, but was easy after creating a template directory tree to hardlink to. 

In the case of mod_php it would need to be a "fake" or internal chroot except for ticks, exec, system, etc calls where it can be safe to do an actual chroot() call since the external process will die off and the mod_php environment left in tact.

Here is a proposal of new settings...

* chroot_basedir:
All file operations are relative to this. Not including ticks, system, exec, dl, etc. Example (pseudo):

  <virtualhost domain.com>
    php_admin_value chroot_basedir = /home/virtual/domain.com
  </virtualhost>

  <?php fopen("/var/www/html/file.php"); ?>

The fopen would actually try to open "/home/virtual/domain.com/var/www/html/file.php". This might cause some overhead per function call. As I haven't even started to look at the best way to implement it I'm just guessing. Maybe the fopen arg can be manipulated the same place open_basedir is checked?


* chroot_execdir:
Jail to be in for ticks, exec, system, dl, etc. Follows same premise as chroot_basedir. Spawn a process chroot'd to this directory then execute the external command. Same way suexec does basically.


I am considering implementing the above. No idea where to start just yet. I *very* briefly fgrep'd php source for occurances of open_basedir to get a quick glimpse. Please contact me with remarks.