Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98280
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 74.125.82.177 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <1FC170E6-5207-45F3-8DF7-8B50787DCCA7@gmail.com>
References: <4CD4DCCC-6643-4A66-B6AD-4BF0EF89FDA9@gmail.com>
 <CAESVnVpFmLuJkSG-znmOyRDh2evcEiv3ZXzQkhoet4r9hekM=A@mail.gmail.com> <1FC170E6-5207-45F3-8DF7-8B50787DCCA7@gmail.com>
Date: Fri, 10 Feb 2017 12:25:54 -0500
Message-ID: <CAESVnVro1_896Kc-1UjbGHixBbdVm2dc-uN0ycAB-pDeZrW4NA@mail.gmail.com>
To: Ben RUBSON <ben.rubson@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Improve (disable|enable)_functions #65386
From: pollita@php.net (Sara Golemon)

On Fri, Feb 10, 2017 at 4:02 AM, Ben RUBSON <ben.rubson@gmail.com> wrote:
>> On 09 Feb 2017, at 18:12, Sara Golemon <pollita@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.

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.

>> 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?

-Sara