From:             [EMAIL PROTECTED]
Operating system: Linux Mandrake 7.2
PHP version:      4.0.6
PHP Bug Type:     *General Issues
Bug description:  allow_url_fopen setting in php.ini ignores the false INI constants

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 

=======================================
-- 
Edit bug report at http://bugs.php.net/?id=15854&edit=1
-- 
Fixed in CVS:        http://bugs.php.net/fix.php?id=15854&r=fixedcvs
Fixed in release:    http://bugs.php.net/fix.php?id=15854&r=alreadyfixed
Need backtrace:      http://bugs.php.net/fix.php?id=15854&r=needtrace
Try newer version:   http://bugs.php.net/fix.php?id=15854&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15854&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=15854&r=notwrong
Not enough info:     http://bugs.php.net/fix.php?id=15854&r=notenoughinfo
Submitted twice:     http://bugs.php.net/fix.php?id=15854&r=submittedtwice

Reply via email to