#28394 [NEW]: Enhancements to safe_mode that will actually make people want to use it.

From: Date: Fri, 14 May 2004 09:48:09 +0000
Subject: #28394 [NEW]: Enhancements to safe_mode that will actually make people want to use it.
Groups: php.bugs 
Request: Send a blank email to php-bugs+get-59611@lists.php.net to get a copy of this message
From: danm at prime dot gushi dot org Operating system: Any PHP version: 4.3.6 PHP Bug Type: Feature/Change Request Bug description: Enhancements to safe_mode that will actually make people want to use it. Description: ------------ Safe mode is useless in a shared hosting environment. A good 50 percent of the scripts that are available for users that are written to take advantage of the power and flexibility of php say right off the bat "this doesn't work if you're running under safe mode". The documentation insists that it's not php's job to handle security, but safe_mode attempts to do it, because all php scripts run as the apache user. What this results in, is any file created by php is unable to be altered or deleted by the regular user via shell/ftp. What needs to happen, realistically, is that all the functions that normally have their behavior changed by safe_mode to do UID/GID checks, should use a suexec-like "wrapper" application (which does the same sorts of checks that suexec does on caller, uid, etc) that will open the filehandle for them with their UID. Rather than PHP having to check the permissions like safe mode does, the job would be given back to the OS where it belongs. This way, you still get the benefit of fast startup, because PHP remains a module (and the wrapper application is small enough to load fast). Of course, this has its dangerous side too, so it would be the type of thing that would be off-by default unless the user had passed all the necessary options to ./configure, like suexec. Does this represent a monumental amount of new code? Yes. However, the place for it is in PHP's core. This is a great idea if officially sanctioned, and an absolutely TERRIBLE idea if written by a third party. Due to the tight nature of integration necessary, this MUST come from "inside". -- Edit bug report at http://bugs.php.net/?id=28394&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28394&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28394&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28394&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28394&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28394&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28394&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28394&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=28394&r=support Expected behavior: http://bugs.php.net/fix.php?id=28394&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=28394&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=28394&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28394&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28394&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28394&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28394&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=28394&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28394&r=float

« previous php.bugs (#59611) next »