ID:               15854
 Updated by:       [EMAIL PROTECTED]
 Reported By:      [EMAIL PROTECTED]
-Status:           Open
+Status:           Closed
 Bug Type:         *General Issues
 Operating System: Linux Mandrake 7.2
 PHP Version:      4.0.6
 New Comment:

Considered closed - please try a CVS snapshot (dated at the time you
read this or later) and reopen if this still applies.



Previous Comments:
------------------------------------------------------------------------

[2002-03-04 04:54:54] [EMAIL PROTECTED]

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 this bug report at http://bugs.php.net/?id=15854&edit=1

Reply via email to