Instead of just giving up on the problem, perhaps we should go into full attack mode. I see a couple of choices (and there are probably others):
1. Review and push open_basedir as the PHP-based jail mechanism 2. Pitch in and get Apache 2's perchild mpm up to snuff. There are all sorts of other issues associated with this option though, like needing to make sure all the stuff we link against is threadsafe. 3. Push FastCGI as the solution based on Shane's latest work on that front 4. Come up with step-by-step idiot-proof instructions for setting up Squid or other reverse proxies and running multiple instances of Apache listening on multiple ports and having requests directed appropriately by something like SquidGuard. I don't mean we should do just one of these, we should perhaps push forward on all fronts and come up with a document that describes the plusses and minuses of each as it applies to large shared hosting scenarios. -Rasmus On 12 May 2002, Stig S. Bakken wrote: > I'm +1 on removing safe mode in PHP 5, and encourage the use of > system-level sandboxes/prisons instead. > > - Stig > > On Sat, 2002-05-11 at 17:39, Ilia A. wrote: > > In the process of writing an installer in PHP for one of my projects I've come > > in contact with a number of servers running PHP with safe_mode enabled. > > > > As you can probably imagine the installer at first broke completely because of > > safe_mode restrictions. Despite the restriction I was able to write php code > > that was able to bypass safe_mode restriction in every single case, which > > should tell you just how "safe" that option is. > > > > There are numerous ways to bypass it, rely on file system utils if they are in > > the path, make the script copy itself and then write stuff as webserver, > > install a small script into cgi-bin directory that will do the same thing > > etc... > > The number of ways to bypass this feature are too numerous to list here. > > > > I should also point out that safe_mode implementation has numerous bugs in > > every PHP version including the very latest CVS. > > > > It is my belief that safe_mode gives people who use false sense of security by > > "supposedly" securing their webserver from their own users, which is > > pointless since a "dedicated user" can cause plenty of damage by using > > while(1) include $PHP_SELF; etc... > > In addition safe_mode makes the developer life extremely difficult since it > > blocks the most common operations that ARE ALLOWED by the webserver's file > > permissions, why does PHP take on the role that is not done in any other > > programming language? > > It is nearly impossible to write a PHP file system code that would work with > > safe_mode it is much easier to just release C/Perl/Python etc.. code that > > will do the very same thing and run via a command line or the user's cgi-bin > > directory. > > For example, if a user uploads test.php with their FTP and test.php creates a > > file, it will no longer be able to read that file under safe_mode since the > > uid of the script and the file it created differ. > > > > IMHO safe_mode should be removed from the php core, because it lulls web > > server admins into false sense of security thus not taking the time to setup > > proper file system permissions in addition to severely crippling the PHP's > > file system functionality. > > > > If the safe_mode like functionality remains it should simply block all file > > system and shell execution code since with it most of that code becomes > > useless anyway. > > > > Regards, > > > > Ilia > > > > -- > > PHP Development Mailing List <http://www.php.net/> > > To unsubscribe, visit: http://www.php.net/unsub.php > > > -- > PHP Development Mailing List <http://www.php.net/> > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
