DreamHost adds PHP 5

Posted Jun 03, 2005 in PHP, Technology, Web Design.

DreamHost are now offering customers a choice in their version of PHP. The default arrangement is for PHP 4 running as a CGI application. Customers have been able to switch to using PHP as an Apache module if they wish. Now, however, the option to run PHP 5 as a CGI application is also available.

In an attempt to encourage developers to adopt best practices, things like register_globals and magic_quotes_gpc have been disabled for PHP 5, although they remain enabled for PHP 4. Across all PHP installations, DreamHost have wisely disabled allow_url_fopen to further improve security. Their new wiki has information about the implications of disabling URL file access, as well as how to get around the issue by using the cURL library.


  1. Gravatar

    I really don't understand. If things like register_globals, magic_quotes_gpc and allow_url_fopen (among others tabooed) are so evil, why are they still present on every PHP release? Do you realize that they are asking you to do with 10 lines of code what you could do with one? And furhter more, one line of a built-in PHP function (fast!).

    I just don't get it. That's why I own my server. Shared hosting companies will one day go down the drain.

    Posted by David Collantes on Jun 03, 2005.

  2. Gravatar

    Combinations of register_globals and allow_url_fopen can cause terrible security risks. In order to protect themselves, and their customers, from poor scripting, they have wisely disabled these options in PHP5 (and in the case of the latter, PHP4 as well). This kind of thing is unacceptable:


    Shared hosting is great for people who aren't doing anything commercial, and pretty good for small business who aren't getting lots of traffic. It'll be around for a long time.

    Posted by Simon Jessey on Jun 03, 2005.

  3. Gravatar

    Simon, you will think what you think and I will think what I think, I am not up to the task to change your mind (and I am sure you neither), still, you have failed to provide an example of the "terrible security risk."

    How the including of an 'evil' website (Microsoft? <grin>) could cause problems? They are 'jails' and other more technical and professional approaches that could be implemented that will not punish justs because of sinners. They have opted to close the water gate because the water is dirty, without bothering on reasoning that perhaps cleaning the water is what's needed.

    I guess I agree with you in one thing: they provide a cheap service to people who can live with cheap things.

    Posted by David Collantes on Jun 03, 2005.

  4. Gravatar

    -- you have failed to provide an example of the "terrible security risk."

    Well one problem is that register_globals does not distinguish between POST and GET variables, so if there has been some poor coding (which is more common than not), it might be possible for someone to append something like "?admin=1" to the end of a URL, and get some sort of administrative access. Here is another example.

    It is surely much better to put the developer in control of such things, even at the cost of a few extra lines of code.

    Posted by Simon Jessey on Jun 03, 2005.

  5. Gravatar

    Thanks for the link to my entry, Simon. :)

    David -- Let me put it to you this way. 99% of the information deemd classified by the U.S. government is not, in and of itself, particularly harmful or sensitive. The reason it is classified is because of the big-picture concept that put together with other crucial pieces of data, we now have a National Security risk or something to that effect.

    David, register_globals is not a bad thing. Neither is include() a bad thing. However, big-picture programming dictates that use of these items in combination with potentially other destructive code (also harmless in itself) could bring down a site, server, or network or compromise critical and possibly sensitive data. See?

    Here's another article in the same series about include(). You can see the problem...

    Posted by Aaron Brazell on Jun 16, 2005.

  6. Gravatar

    Thanks for your additional input, Aaron. I appreciate that :)

    Posted by Simon Jessey on Jun 17, 2005.