|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
[2002-04-16 18:21 UTC] wez@php.net
[2005-06-22 10:20 UTC] nickj-phpbugs at nickj dot org
[2005-06-22 12:47 UTC] sniper@php.net
[2005-06-22 14:05 UTC] tony2001@php.net
[2005-06-25 03:18 UTC] nickj-phpbugs at nickj dot org
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2024 The PHP GroupAll rights reserved. |
Last updated: Mon Dec 30 14:01:28 2024 UTC |
Before: The output of phpinfo(), in the "Configuration - PHP Core" section, for the "allow_url_fopen" directive says "no value" for both "Local Value" and "Master Value". Aim: To set the allow_url_fopen to say off / disabled, as opposed to "no value", for a more secure PHP installation. Changes made: To the /etc/php.ini, tried adding the following lines, one at a time, then restarting the web server, then checking the output of phpinfo(): allow_url_fopen = False ; allow_url_fopen = false ; allow_url_fopen = Off ; allow_url_fopen = off ; After: The output of phpinfo(), in the "Configuration - PHP Core" section, for the "allow_url_fopen" directive _still_ says "no value" for both "Local Value" and "Master Value" in all of the above cases. What _does_ fix this problem: Using the integer value, like so: allow_url_fopen = 0 ; In this case the value prints as "0". What does work as expected: Basically, all the true cases that I tried, namely: allow_url_fopen = 1 ; allow_url_fopen = True ; allow_url_fopen = true ; allow_url_fopen = On ; allow_url_fopen = on ; In all of these cases the value prints as "1". Why this is a problem: Besides being completely inconsistent, it also does not comply with the documentation: The php.ini file says this: > The value can be a string, a number, a PHP constant (e.g. E_ALL or M_PI), one > of the INI constants (On, Off, True, False, Yes, No and None) or an expression > (e.g. E_ALL & ~E_NOTICE), or a quoted string ("foo"). Furthermore many of the values in the php.ini file are either "On" or "Off". Most normal people would thus quite reasonably assume that the same consistent syntax would also work for allow_url_fopen, and it does, but only if you want to enable it, not if you want to disable it (which is what most people would probably want to do) [**bangs head repeatedly against table**]. Answers to the questions I expect you to ask: There is no duplicate existing line that is overwriting the value of the allow_url_fopen directive, as evidenced by this: =================================== [root@dev ~]# grep -i "fopen" /etc/php.ini ; prevent the URL-aware fopen wrappers from accessing URL objects allow_url_fopen = 0 ; =================================== I know that I am editing the correct php.ini file, because it can be made to work, but only if I change the value to any true/on/1 value, or to 0. This is not a brand new problem. The same problem happened in PHP 4.04pl1, but I gave up looking harder at it then when I could not get "False" or "Off" to work straight away. I had hoped that upgrading to PHP 4.06 might make it go away, but no joy. I only found that 0 or 1 work out of an annoyed determination to try everything when upgrading to 4.06 due to recent security updates. Evidence that this has bit other people in the ass too: I have searched the PHP bugs database, and noticed that someone else has experienced something similar, but it is included as a side note in a bug report (not as the main content): http://bugs.php.net/?id=12748 The reporter of that bug (#12748) wrote: > When I leave out the setting in httpd.conf, and just have > "allow_url_fopen = Off" in the php.ini file, phpinfo() has > "no value" written for the Master Value and Local Value. Recommendation: _Please_ fix the "allow_url_fopen" directive to work with _all_ the INI constants - namely "On, Off, True, False, Yes, No". My configuration information: These PHP packages are using the distro's RPMs, namely: php-4.0.6-5.7mdk.i586.rpm, php-common-4.0.6-5.7mdk.i586.rpm, php-devel-4.0.6-5.7mdk.i586.rpm Am I willing to update to whatever the latest and greatest PHP version is right now?: Absolutely not. I've got what I have to work, but I want to stop this from being a problem for anyone else (or myself in two year's time). The top bit of phpinfo() shows this: ======================================= PHP Version 4.0.6 System Linux updates.mandrakesoft.com 2.4.8-34.1mdkenterprise #1 SMP Mon Nov 19 11:56:45 MST 2001 i686 unknown Build Date Feb 27 2002 Configure Command './configure' '--disable-static' '--disable-debug' '--disable-rpath' '--enable-pic' '--enable-inline-optimization' '--prefix=/usr' '--with-zlib' '--with-config-file-path=/etc' '--enable-magic-quotes' '--enable-debugger' '--enable-track-vars' '--enable-safe-mode' '--with-exec-dir=/usr/bin' '--with-regex=system' '--with-versioning' '--enable-sysvsem' '--enable-sysvshm' '--with-mod_charset' '--enable-force-cgi-redirect' '--with-mm' '--enable-trans-sid' '--with-dbase' '--with-filepro' '--enable-yp' '--enable-ftp' '--with-xml' '--with-gettext' <br>[Some modules are external: look for packages php-pgsql,php-mysql,...] Server API Apache Virtual Directory Support disabled Configuration File (php.ini) Path /etc/php.ini ZEND_DEBUG disabled Thread Safety disabled This program makes use of the Zend scripting language engine: Zend Engine v1.0.6, Copyright (c) 1998-2001 Zend Technologies with Zend Optimizer v1.2.0, Copyright (c) 1998-2001, by Zend Technologies =======================================