I fail to see where the documentation was not enough precise.
If you read http://php.net/ref.filesystem#ini.allow-url-fopen
or http://php.net/features.remote-files.

It's clearly stated that this directive affects the possibility to use URL wrappers. Thus, every functions allowed to use such wrappers (or URL-aware) will be affected.

Notice that the configuration directive "allow_url_include" exists since PHP 6, to adress this very "security problem".

Well, no point in "http://php.net/ref.filesystem#ini.allow-url-fopen" nor in 
"http://php.net/features.remote-files" nor in
the comment in the configuration file
explains anything about bypassing any restriction, does it?

Additionally, nobody firstly taking some existing project in use will look in the deepth of the PHP-documentation when he tries to setup his server to get that application running, does he?

Additionally, how many people using tools like dreamwaver will be looking at php code at all, for the only use of using those tools is often to just avoid having to go into the deepths of programming?
At least in my environment i precisely encountered just such a case yesterday.
From the structure and the automatically generated comments in the php and html code i can clearly see, that the coding person has possibly not even taken a single look at the html and php code.

Maybe, the documentation is not meant for those peoples. But for those really coding php and configurating servers, i would find it nice if there were some usefull hint at precisly that point in the documentation, where this directive is described, about the side effects (circumvention of restrictions).

For me, when i firstly did setup my home server, i did setup several security settings, including register_globals to off and a restrictive execution path. Everything according to the documentation available to that point. Explicitely with reading the documentation about all and every configuration directive including "allow_url_fopen", being "on" per default and not documented to any degree about side effects. I believed in being on the secure side. Then, yesterday, i had to begin to work on a foreign project, temporarily moved onto my believed to bo secure server. The project simply used some replacement for some "include". In the very same moment, my server would have been open to the wide wild world. If that "allow_url_fopen" had been documented sufficiently, it would never have been enabled on my server.

To the last: _I_ didn't open the project to the WWW before i looked through the code and tested some intrusions. _I_ realized the problem, searched the internet and found those entries alredy two years old in the "c't" and in various forums. But how many hobby-webmasters will do so before they are affected?

I think, the entry in the documentation would be 4...5 lines of a few words (example given above). So it is not very usefull to do such a prolonged discussion here about such a simple matter...

What are you talking about when speaking about "bypassing any restriction" ?

Quite every configuration directive is documented in the manual. Any capable host is able to read the doc, expressing pretty well what the role of allow_url_fopen is:  http://php.net/manual/en/ini.php .

Remember, allow_url_fopen is a completely secure feature unless _you_ screw it.

Would you also like having a warning "including tainted client data in the argument is dangerous" in about each filesystem functions, like unlink() ?

If I understand you correctly, you want to have a warning somewhere about the danger of using code like include $_GET['page']; ? This security hole is not only related to allow_url_fopen, requesting page.php?page=/path/to/secret_file is posible even with allow_url_fopen disabled.

The documentation about allow_url_fopen is fine. But maybe a security paragraph like http://php.net/session#session.security would be useful.

There is already:

http://php.net/security.filesystem
http://php.net/security.variables

So I really can't think about a possible improvement.

It seems that this manual page[1] needs some fixes and is not really up to date. I'll also add something about the "include security hole".

[1] http://php.net/security.filesystem

Well, when i look at the intrusion attempts on my server, for example (cut off from the log):

req:"GET /index2.php?option=com_content&do_pdf=1&id=1index2.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=...
req:"GET /index.php?option=com_content&do_pdf=1&id=1index2.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=...
req:"GET /mambo/index2.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=...
req:"GET /Mambo/index2.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=...
req:"GET /news/index2.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=...
req:"GET /home/index2.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=...
req:"GET /cvs/index2.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=...
req:"GET /index.php?option=com_content&do_pdf=1&id=1index.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=...
req:"GET /mambo/index.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=...
req:"GET /Mambo/index.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=...
req:"GET /news/index.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=...
req:"GET /home/index.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=...
req:"GET /cvs/index.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=...


then it seems that there are at least _a_few_ people out there not being able to read the "pretty well" documentation while being able to program wide spread public programs versus being able to setup servers.
They are, of course, only extremely rare exceptions!

OK, i have done all i could to help those guys. If it shouldn't be, then i will let it be.

your latest comment have nothing to do with allow_url_fopen..looks like that is a combination of a MOS bug with the GLOBALS overwrite issue detected by Steffan Esser some time ago..

adittionally buggy code like include $_GET['page']
 can be exploited even with allow_url_fopen , to read local files, or arbitrary code execution tricking the php://input wrapper ( that do not obey allow_url_fopen at all) I think this last point,and the NULL byte attack
should be mentioned in the security docs too..

in my latest comment I really mean "even **without** allow_url_fopen enabled"

PLEASE SEND SOME SAMPLE TEST CASES OF WEB APPLICATION AND CLIENT SERVER APPLICATION

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation better.

some improvements