I posted this as a response to bug #22410, but taking a chance to open it as a new feature request.

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.