php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #50802 Allow "disable_functions" in httpd.conf
Submitted: 2010-01-19 20:20 UTC Modified: 2010-01-29 15:45 UTC
Votes:19
Avg. Score:4.9 ± 0.4
Reproduced:18 of 18 (100.0%)
Same Version:3 (16.7%)
Same OS:8 (44.4%)
From: h dot reindl at thelounge dot net Assigned:
Status: Wont fix Package: Feature/Change Request
PHP Version: 5.2.12 OS: All
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: h dot reindl at thelounge dot net
New email:
PHP Version: OS:

 

 [2010-01-19 20:20 UTC] 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

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-01-19 20:22 UTC] rasmus@php.net
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:30 UTC] 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:37 UTC] rasmus@php.net
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:47 UTC] h dot reindl at thelounge dot net
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
 [2010-01-29 14:43 UTC] h dot reindl at thelounge dot net
http://www.webhostingtalk.com/showthread.php?t=623944

If it is not possible because performance why it works with suhosin-extension perfectly with the only problem that "function_exists()" does not realize the suhosin setting?

Sorry, but this sounds like "it's possible but i say is not because i do not like to touch the code"
 [2010-01-29 15:39 UTC] rasmus@php.net
Suhosin doesn't disable functions.  It adds a separate blacklist 
mechanism.  This bug was about being able to do per-request disabling 
with the existing disable_function mechanism.
 [2010-01-29 15:45 UTC] h dot reindl at thelounge dot net
> Suhosin doesn't disable functions.  
> It adds a separate blacklist 
> mechanism.  

Yes, and it works fine

> This bug was about being able to do per-request disabling 
> with the existing disable_function mechanism.

And shows that the existing mechnism is poorly implemented if you need a extension to make a SECURITY-SETTING usable which is able to do nearly the same and would not be needed if the php-core does handle this better
 [2012-01-30 02:23 UTC] k dot reznichak at pcpin dot com
Hello, any updates here?

Doesn't matter if "suhosin"-like or any other way, this feature would dramatically simplify server administration and reduce costs. My current solution with different apache instances listening on different ports via proxy was pain to set up and hurts every time I manage it.

Please consider that some admins just going easy way by enabling sensitive functions globally for all virtual hosts causing security risk. That does not means PHP is insecure by itself, however it encourages people to act insecure.

Kind Regards
 [2013-06-30 20:14 UTC] spamik at yum dot pl
disable_functions should be made PHP_INI_ALL with exception that once set in can't 
be set to less restrictive (like open_basedir is nowadays). Yes it is tought to 
make because of curent code, but that is no reason to reject feature request 
completly! Don't reject it, maybe some dev someday will find motivation to do 
this.
 [2017-03-16 01:34 UTC] own3mall at gmail dot com
In nginx, with fastcgi you can override the setting in the template:

fastcgi_param  PHP_ADMIN_VALUE "disable_functions=exec,passthru,shell_exec,system,proc_open,popen";

And, it WORKS there.

OK, so why can't we do this with php in Apache2?  Surely, the performance wouldn't be that much of a hit.  I don't want to disable the above functions globally since some of my sites absolutely need some of those functions, but shared hosting users shouldn't be able to run them.

I also don't want to use Suhosin, period.

Surely this can be fixed to work on Apache2 as it does with nginx and php-fpm?
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Oct 31 22:01:27 2024 UTC