#28394 [Opn->Fbk]: Enhancements to safe_mode that will actually make people want to use it.

From: Date: Fri, 14 May 2004 10:37:38 +0000
Subject: #28394 [Opn->Fbk]: Enhancements to safe_mode that will actually make people want to use it.
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-59612@lists.php.net to get a copy of this message
ID: 28394 Updated by: wez@php.net Reported By: danm at prime dot gushi dot org -Status: Open +Status: Feedback Bug Type: Feature/Change Request Operating System: Any PHP Version: 4.3.6 New Comment: You're welcome to write a patch that does all this. If it works better than safe_mode, and doesn't make things slower for people that don't need it, then there is a chance it will be accepted. Previous Comments: ------------------------------------------------------------------------ [2004-05-14 11:48:06] danm at prime dot gushi dot org 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 this bug report at http://bugs.php.net/?id=28394&edit=1

« previous php.bugs (#59612) next »