Nicolas Bérard Nault writes: > If a programmer is not capable of controlling an user input,
You are making a mistake here. You are assuming that the user realized that 'include' is really 'includeremotesecurityhole'. Consider the security implications of a user 'include'ing a file that doesn't exist (because the attacker used a different filename). Pretty small. They would be akin to what happens when you specify an .html file that doesn't exist. Generates an error; no big deal. Do you see? Your assumption proves my point: that the naive user doesn't see any sharp edges on 'include' and doesn't worry about it. > I think if a programmer can't read a manual page about a so common > function, he deserves what he has. If 'strchr' caused your CPU's fan to stop turning, should 1) a work-around be documented, or 2) the code fixed? If a bug in libjpeg allows a url_fopened image to contain invalid data that elevates privilege, should that be 1) a work-around be documented, or 2) the code fixed? If the design of 'include' allows remote users to execute hostile code, should that be 1) a work-around be documented, or 2) the code fixed? > Are you suggesting that virtually _any_ function should be > protected against stupidity ? If people do stupid things with a computer, is it their fault or the computer's fault? Personally, I always think it's the computer's fault. So, yes, if people end up doing stupid things, it is because the computer is wrong. -- --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
