Req #50802 [Com]: Allow "disable_functions" in httpd.conf
| From: | k dot reznichak at pcpin dot com | Date: | Mon, 30 Jan 2012 02:23:04 +0000 |
| Subject: | Req #50802 [Com]: Allow "disable_functions" in httpd.conf | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-166937@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=50802&edit=1
ID: 50802
Comment by: k dot reznichak at pcpin dot com
Reported by: h dot reindl at thelounge dot net
Summary: Allow "disable_functions" in httpd.conf
Status: Wont fix
Type: Feature/Change Request
Package: Feature/Change Request
Operating System: All
PHP Version: 5.2.12
Block user comment: N
Private report: N
New Comment:
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
Previous Comments:
------------------------------------------------------------------------
[2010-01-29 15:45:08] 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
------------------------------------------------------------------------
[2010-01-29 15:39:30] 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 14:43:51] 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-19 20:47:32] 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-19 20:37:26] 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.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=50802
--
Edit this bug report at https://bugs.php.net/bug.php?id=50802&edit=1