On Mon, 2002-05-13 at 04:11, Zeev Suraski wrote: > At 11:42 13/05/2002, veins wrote: > > > He has a point in the sense that it's trivially easy to starve a PHP based > > > web server from within, safe mode enabled or not. What you describe as > >the > > > automated way in which the web server will overcome this attack is not > > > realistic - pretty quickly, the web server would hit the maximum number of > > > children allowed, or (if improperly configured) run out of memory. > > > >This is not PHP related. A web server improperly configured would run out > >of memory under a heavy load or with a CGI script. > > Right, I didn't suggest otherwise. > > > > Fact is, safe mode doesn't even attempt to guard against this. Not that I > > > think it can be guarded against, even if we were trying to do it. And a > > > direct derived fact is that PHP is not safe to allow untrusted users to > >run > > > code. > > > >I happen to think that allowing untrusted users to run PHP code is safer > >than > >allowing them to run a CGI script, even if PHP is not under safe_mode and > >that CGI is chroot()-ed. > > I don't agree with that. chroot() is stronger than anything PHP can ever > hope to offer. > > >I don't. I don't see safe_mode as a "false sense" of security, I see it as > >another > >layer to be used with other security mechanisms. > > I do, for two simple reasons: > - Misperception about what it's supposed to do - it does NOT secure your > environment, people expect it to. That's a 'marketing' issue, but we > should realize that these kinds of issues are at least as important as the > technical ones.
I get the feeling that you are mainly arguing the marketing perspective. : ) I completely agree that safe mode is badly named. However, I still find uid checking, and restricting process spawning very useful > - Inherent flaws in the way it does what it IS supposed to do. Guarding > users against each other at this level is a lost cause. Even if you know > perfectly well what safe mode's supposed to do, whatever sense of security > you get from it is false, because there are always going to be slightly > more or slightly less trivial ways of defeating it. > >Encouraging people to use CGI is an utopia, there are environnements where > >CGI cannot be "offered" to customers and where PHP is the only option. > > I don't think you understood the context. We're talking about the PHP CGI, > not CGI in general. > Zeev > -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
