Re: allow_url_fopen should be INI_ALL

PHP is not, in my opinion, idiot-proof. You're right on that point. Where our opinions differ is about what should be done about this. If a programmer is not capable of controlling an user input, why then should we trust him with anything ? A lot of other functions taking user input as arguments could potentially be as damaging as this one. I think if a programmer can't read a manual page about a so common function, he deserves what he has. Yes, I'm feeling a bit pre-conventionnal tonight. As for the rm -rf / case, I think it's the best exemple. Why should a hacker bother on exploiting an include stupidly called with user input unfiltered when he can get straight to an unprotected system($_GET['Whatever']). Are you suggesting that virtually _any_ function should be protected against stupidity ? What kind of language PHP would be after that ? On 6/29/05, Russell Nelson <nelson@crynwr.com> wrote: > Gareth Ardron writes: > > To me, it's obvious that include includes a file - I see no obvious > > determination that that file is either local or remote in the "include" > > statement. > > Can you name some other languages in which 'include' has such > incredibly sharp edges? C? Python? Perl? BASH? Sed? Awk? Pascal? > BASIC? Is there *any* precedent for a language in which 'include' > will fetch hostile code from a remote server and execute it? If > you're going to argue that experienced programmers will understand > that 'include' will fetch code, you should explain how their > experience helps them. > > > Also, I think it's silly to make include into two functions as you > > suggest given that the ability to include a remote file depends on the > > fopen wrapper being enabled. If we were to follow this line of logic, we > > would have two functions for every current one function which can use > > the fopen wrappers. > > That's not my line of logic, so following it takes you off the map. > > > I think the documentation quite clearly states that /all/ functions that > > deal with files may deal with remote files if the fopen wrappers are > > enabled > > Why did both of my users miss that documentation? The facts seem to > be in opposition to your assertion that "the documentation quite > clearly states". > > > However, as I mention above, every single function that can use > > fopen wrappers can be exploited in this way. > > Not true. You would need to have *another* security flaw (a bug in > jpg or xml parsing) for hostile jpg or xml content to gain privileges. > > > It's unfortunate, but there's a lot of muppets out there who think > > they can code > > Now you're blaming the victim. > > -- > --My blog is at blog.russnelson.com | If you want to find > Crynwr sells support for free software | PGPok | injustice in economic > 521 Pleasant Valley Rd. | +1 315-323-1241 | affairs, look for the > Potsdam, NY 13676-3213 | | hand of a legislator. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Nicolas Bérard Nault (nicobn@gmail.com) "Maybe nature is fundamentally ugly, chaotic and complicated. But if it's like that, then I want out." -- Steven Weinberg (prix Nobel de physique, 1979).