> On 10 Feb 2017, at 18:25, Sara Golemon <poll...@php.net> wrote:
>
> On Fri, Feb 10, 2017 at 4:02 AM, Ben RUBSON <ben.rub...@gmail.com> wrote:
>>> On 09 Feb 2017, at 18:12, Sara Golemon <poll...@php.net> wrote:
>>> Could you clarify? `disable_functions` *IS* a PHP_INI_SYSTEM directive:
>>>
>>> PHP_INI_ENTRY("disable_functions", "", PHP_INI_SYSTEM, NULL)
>>
>> However, as per all the bugs referenced by #65386,
>> using "php_admin_value disable_functions" in httpd.conf does not correctly
>> work.
>> The main issue certainly is that it can't be used per vhost.
>> (note that it however still affects their local ini value)
>>
> That's not surprising. When disable_functions processes an INI
> change, it's a one-way affair. Any functions listed in the INI
> setting are clobbered and their original handlers are lost (on
> purpose, I imagine).
>
> When a new setting comes in to override it (via php_admin_value) it
> can only add to the list of disabled functions, not restore previously
> disabled functions.
I was talking more specifically about the following :
"php_admin_value disable_functions mydisfunction"
phpinfo() shows mydisfunction as locally disabled,
but in reality can still be used.
So "php_admin_value disable_functions" should not affect "Local Value".
(as per point 1 of #65386)
But should also be solved by allowing "php_admin_value disable_functions"
to really disable functions :)
(as per point 2 of #65386)
> Again, I'm not certain, but my gut says this was intentional.
>
>>> There's also a technical hurdle here due to the way that functions are
>>> (currently) disabled. It's INI_SYSTEM because enabling/disabling on a
>>> per-request (per vhost essentially means per request) basis means a
>>> lot more heavy lifting than disabling on a system-wide level (we just
>>> replace the function implementation in the global table with a STFU
>>> message).
>>
>> Sounds like it would then require some dev to achieve this behaviour.
>> Would it however hurt requests performance ?
>>
> TL;DR - Yes.
>
> If you want a single process to serve some requests with function X
> disabled and some to serve it with that function enabled, then SOME
> amount of per-request processing has to be done. Maybe it's done on
> RINIT to shuffle around the function table, maybe it's done at
> function call time via a flag, maybe it's done by compiling to a
> different instruction for "potentially disabled function call". I'm
> not sure as I haven't thought very far into the problem.
Perhaps initial init time could be a little bit longer, but to the benefit
of non-slowed requests.
OK, understood, thank you !
Any way to "officially" add these requests (#65386) to the development list ?
>>> but if the goal is to
>>> disable an entire extension's worth of functions, wouldn't one
>>> just.... not load that extension?
>>
>> Because one would certainly want to re-enable one of these functions in
>> one of its vhosts (or even globally in php.ini) :)
>>
> Is running separate fcgi instances not an option here?
Of course running separate fcgi instances could be a solution to run
different configurations.
But even here, the wildcards with the ability to use enable_functions
would really be helpful.
Thank you again !
Ben
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
