ID:               50802
 User updated by:  h dot reindl at thelounge dot net
 Reported By:      h dot reindl at thelounge dot net
 Status:           Wont fix
 Bug Type:         Feature/Change Request
 Operating System: All
 PHP Version:      5.2.12
 New Comment:

Hm very bad - so i have three choises

* allow a function i would never like on all hosts
* make a own httpd-instance for 2 vhosts
* change the whole company-infrastructure especially adminpanel

> The performance hit would be way too high

About what time-gain are we speaking?
I can not believe that refresh this list takes a really long time
With open_basedir it works also and you have to check this before every
fs-operation - where is the difference and would it not make sense to
look how to optimize initalizing the functon table?

> I agree with you that the phpinfo() out is misleading, 
> but that's not what you filed a bug about.

Of course i have because i saw this day that a function is active that
should not and i never ever would have configured the machine this way
if phpinfo() had not shown me that the configuration is active


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

[2010-01-19 20:37:26] [email protected]

Of course it is per-request.  The same Apache/PHP process will handle 
different virtual hosts from one request to the next.  Allowing per-
dir/per-vhost changing of the function table would mean we have to 
reload the function table on each and every request.

I agree with you that the phpinfo() out is misleading, but that's not 
what you filed a bug about.

------------------------------------------------------------------------

[2010-01-19 20:30:38] h dot reindl at thelounge dot net

Are you sure that this is "per-request"?

It must not be allowed in htaccess because the ftp-owner could change
It should be only read at startup with the server-configuration like
"open_basedir", the really working security-settings per host you get
only while combine "open_basedir" and "disable_functions"

In some situations this would mean you need a own apache-instance with
a own "php.ini" on an internal port and a proxy-configuration outside
what is not nice to administrate

However, phpinfo() never should show ignored values from httpd.conf or
.htaccess because this is the place where the developers will look and
if you confiure settings that not shown in php.ini you see this in
phpinfo() and can take a look why

------------------------------------------------------------------------

[2010-01-19 20:22:55] [email protected]

It is not technically feasible to support per-request changing of the 
function table, sorry.  The performance hit would be way too high to be

useful.  This can only be set at startup which is why it is php.ini 
only.

------------------------------------------------------------------------

[2010-01-19 20:20:20] h dot reindl at thelounge dot net

Description:
------------
http://de2.php.net/manual/en/ini.core.php#ini.disable-functions
> This directive must be set in php.ini For example, 
> you cannot set this in httpd.conf

This is a very bad behavior in shared-hosting-environments
You can not enable any function for specific hosts while they must not
be executed in other ones. If you have many vhosts with very straight
security-settings and need a function like "popen" in only one virtaul
host that is fully crontrolled by the admin you have no way to configure
this

What makes this really critical is that "phpinfo();" shows the
local-value from vhost-configuration instead of the effective, it should
always show the working configuration instead of ignored settings.

Reproduce code:
---------------
 <Directory "/docroot">
  php_admin_value open_basedir "/docroot"
  php_admin_value disable_functions "popen, pclose, exec, passthru,
shell_exec, system, proc_open, proc_close, mail, symlink"
 </Directory>



Expected result:
----------------
Disallow the listed functions for the virtual host

Actual result:
--------------
phpinfo(); shows them as disabled but they are working


------------------------------------------------------------------------


-- 
Edit this bug report at http://bugs.php.net/?id=50802&edit=1

Reply via email to