#23612 [NEW]: new "Security" related settings

From: Date: Tue, 13 May 2003 15:23:24 +0000
Subject: #23612 [NEW]: new "Security" related settings
Groups: php.bugs 
Request: Send a blank email to php-bugs+get-39533@lists.php.net to get a copy of this message
From: dale at daledude dot com Operating system: linux rh 7.2 PHP version: 4.3.2RC2 PHP Bug Type: Feature/Change Request Bug description: new "Security" related settings 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. -- Edit bug report at http://bugs.php.net/?id=23612&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=23612&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=23612&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=23612&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=23612&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=23612&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=23612&r=support Expected behavior: http://bugs.php.net/fix.php?id=23612&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=23612&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=23612&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=23612&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=23612&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=23612&r=dst IIS Stability: http://bugs.php.net/fix.php?id=23612&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=23612&r=gnused

« previous php.bugs (#39533) next »