FastCGI can provide the security needed in shared environments, without loosing all the performance. I don't beleive it is fast as direct server plugins, but there are other benefits...such as running PHP single threaded to avoid thread issues. It would be nice to see it become a standard compile option. One thing that does need to happen is a multithreaded fastcgi option for PHP. I've had that in the back of my head but haven't gotten around to it yet. Shane
Rasmus Lerdorf wrote: > 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
