Req #50802 [Com]: Allow "disable_functions" in httpd.conf
| From: | spamik at yum dot pl | Date: | Sun, 30 Jun 2013 20:14:44 +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-179991@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: spamik at yum dot pl
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:
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.
Previous Comments:
------------------------------------------------------------------------
[2012-01-30 02:23:04] 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
------------------------------------------------------------------------
[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
------------------------------------------------------------------------
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