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