PHP's allow_url_fopen option


I got this announcement:

[quote]We apologize for any inconvenience we may have caused. We were initially hasty when we
announced that allow_url_fopen would be turned off immediately as many of your websites
(many more than we had anticipated) rely on it for their functionality . The security issue for
our servers is still severe and we will still be turning off the allow_url_fopen option soon, but
anyone who is currently relying on it will have some time to make the necessary code changes.
This will be your only announcement regarding this and you must make any necessary code
changes before the deadline.

The deadline for any PHP code changes is March 29, 2005. We will be turning off the
allow_url_fopen option shortly after that date.

If you are currently using this functionality in your PHP code, there is a more powerful and
flexible option available. PHP provides excellent support for curl library and its associated

One of our own users has written a short article describing how it is used and that can be found

The official PHP documentation for it is here:

This change will significantly improve the security of PHP-based applications running on our
servers so we can spend more time giving you more features!

Happy DreamHost Keeping-The-Peace and Security Team
I’m running SMF on the server. Is it affected? Do I need to do something?


Search through the .php files of SMF for allow_url_fopen . If you find the function (which I doubt), then SMF will attempt to use it and you will have problems.
I don’t work here. I’m just your typical support forum volunteer.

grep -r fopen * produces some hits.

From the sound of it SMF will work with allow_url_fopen disabled, but the package manager isn’t going to work.

The allow_url_fopen setting affects any file open functions so it affects include, file_get_contents, fopen, etc. A list of PHP’s filesystem functions is here:

You should ask the developers of the software you are using if disabling the allow_url_fopen setting will break anything.

A good place to start researching may be here:

  • Dallas
  • DreamHost Honcho

Well, here we at 20:20 hours on the 29th, and I am waiting with “bated breath” to start testing my sites for any unexpected effects of the setting allow_url_follow to off…but PHPinfo keeps reporting it as on.

It’s a little frustrating, as I held off on continuing some development until I addresssed any anomalies introduced by this change to the PHP environment (and I had just about gotten used to the PHP-CGI methodologies and certian work-arounds) at Dreamhost.

On the whole, I think I would rather have the most secure environment possible, but am not excited about possibly having to code a bunch of curl around exisitn code. I’m espe ially concerned about any effect on Mambo CMS, as I have numerous instances installed.

If any have found the allow_url_fopen option setting disabled on your server could you please report your experience.

If a change is coming, and announced, it ought to come! Dreamhost still rocks, even though sometimes it is the boat that is rocking :wink:


I am having trouble posting so I’ll try again.

I am using code like this:

<?php if(phpversion() >= "4.2.0") { extract($_SERVER); } $badbot = 0; /* look for the IP address in the list file */ $filename = "list.dat"; $fp = fopen($filename, "r") or die ("Error opening file ... \n"); while ($line = fgets($fp,255)) { $u = explode(" ",$line); if (ereg($u[0],$REMOTE_ADDR)) {$badbot ;} }and it won’t work due to recent DH changes.

So why does this code still work from another php file in a different directory?

<?php $badbot = 0; /* scan the list.dat file for addresses of SPAM robots to prevent filling it up with duplicates */ $filename = "../list.dat"; $fp = fopen($filename, "r") or die ("Error opening file ... \n"); while ($line = fgets($fp,255)) { $u = explode(" ",$line); if (ereg($u[0],$REMOTE_ADDR)) {$badbot ;} } Isn’t it doing pretty much the same thing by using fopen?


Both pieces of code should work. The option that was turned off was disallowing fopen to open up any file that starts with http://, https:// or ftp://.

It should have no effect on opening files on your local file system.

Thanks for the reply. The code stopped working on April 2nd on all my sites - at the same time. I had to remove it because my sites were throwing errors and were not working properly. But I guess I’m out of luck because DH doesn’t support third party but this just started happening all of a sudden without anything done on my end. I’ve been using it for months with no problem. Lovely.

G’day, Hope.
If you haven’t already done so, you could try contacting the script’s author for some assistance.
All the best -

Yes, I did contact him. He also said the script should not have been affected.


Is there a specific error message? do you know for sure it’s the fopen call thats dying?

-Jason - Home Page
MP3Mystic - Personal Streaming Music server.
(Neither of these sites are still hosted at dreamhost)

Hi Jason,

I’ll enable the file again and post the error message here in a little while. I have a teleconference to attend in a few minutes but will get to it after that.



Okay. This is strange. The code works from the home page but does not work when called from an inside page. It was not working from either the other day yet both had worked prior to 4/2. Here is the code on the inside pages and home page:

<?php include($_SERVER['DOCUMENT_ROOT'] . "/list.php"); ?>Here is the message I get when it’s called from the inside page:

Warning: fopen(list.dat): failed to open stream: No such file or directory in /home/.paint/username/ on line 8 Error opening file ...Here are lines 7 and 8 of the php file:

$filename = "list.dat"; $fp = fopen($filename, "r") or die ("Error opening file ... \n");And yet the file is definitely there. Both list.php and list.dat are at the root - such as

Does the above help in accessing the matter?

Thanks, I really appreciate the help!


try, for testing, hardcoding it to:


(Leaving out the machine name “.paint”).

-Jason - Home Page
MP3Mystic - Personal Streaming Music server.
(Neither of these sites are still hosted at dreamhost)

Changing code from this: <?php include($_SERVER['DOCUMENT_ROOT'] . "/list.php"); ?>to this:<?php include($_SERVER['DOCUMENT_ROOT'] . "/home/username/"); ?>Caused this:
Warning: main(): open_basedir restriction in effect. File(/home/username/ is not within the allowed path(s): (/dh/web/phpmyadmin:/tmp:/dh/solidclient:/usr/local/lib/php:/home/username:/home/.paint/username) in /home/.paint/username/ on line 24

Warning: main(/home/username/ failed to open stream: Operation not permitted in /home/.paint/username/ on line 24

Warning: main(): Failed opening ‘/home/username/’ for inclusion (include_path=’.:/usr/local/lib/php’) in /home/.paint/username/ on line 24

It should be this:<?php include($_SERVER['DOCUMENT_ROOT'] . "/list.php"); ?>or this:<?php include("/home/username/"); ?>--------------------
Simon Jessey
Keystone Websites | si-blog

When I changed to this:

<?php include("/home/username/"); ?>I get the same error as when I first started. However, I just copied the list.dat file into the subdirectory ( rather than have it at the root and now it’s working. How can I get the list.dat to work at the root? Otherwise, I’ll have to add list.dat into every subdirectory and that’s not an option.
Part of the code is above:]
I have no idea why it isn’t working from a subdirectory now when it was before. And not just on one site. Very strange.

Thanks again.


In the first part of the list.php code I changed it to this (changed line is bold):

<?php if(phpversion() >= "4.2.0") { extract($_SERVER); } $badbot = 0; /* look for the IP address in the list file */ [b]$filename = "/home/username/";[/b] $fp = fopen($filename, "r") or die ("Error opening file ... \n"); while ($line = fgets($fp,255)) { $u = explode(" ",$line); if (ereg($u[0],$REMOTE_ADDR)) {$badbot++;} }it was this $filename = "list.dat";Now it works from any directory.

Forgive my lack of knowledge but is that line okay to have in the list.php file at the root? I mean, is it something someone could hack? Or was it better off the other way without the home/username/ exposed? I hope that makes sense. Just worried about security and all that.


No comments about whether adding the line:
"/home/username/"; to a php file at my root directory would cause a vulnerability? Surely someone would know? Or should I write to support?



[quote]No comments about whether adding the line:
"/home/username/"; to a file at my root directory


What’s in the list.dat file? If it’s at all sensitive information, it’d probably be best to store it somewhere in your home directory instead (ie. /home/username/list.dat).

  • Jeff @ DreamHost
  • DH Discussion Forum Admin