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".