It may not be the fastest solution, but certainly a secure one. It is up to each admin to decide whether they want speed or security, I am sure the security minded ISPs probably would prefer a small performance loss over security & integrity of their customer's data.
Ilia On May 12, 2002 05:42 pm, Rasmus Lerdorf wrote: > Ok, but dropping to CGI is kind of crappy. Especially on a really busy > server. > > On 12 May 2002, Stig S. Bakken wrote: > > Well, as long as there is exec(2), there is a way. How many users do > > Lycos Europe provide sandboxed PHP for? > > > > - Stig > > > > On Sun, 2002-05-12 at 23:37, Rasmus Lerdorf wrote: > > > But for really large shared hosts, I don't think that is feasible. How > > > are you going set up 100,000 prisons on a server? > > > > > > > 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
