Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98282
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.178 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
In-Reply-To: <CAESVnVro1_896Kc-1UjbGHixBbdVm2dc-uN0ycAB-pDeZrW4NA@mail.gmail.com>
Date: Fri, 10 Feb 2017 22:09:49 +0100
Content-Transfer-Encoding: quoted-printable
Message-ID: <FBB16247-67F1-4A34-8AF1-D25DF8C2DC61@gmail.com>
References: <4CD4DCCC-6643-4A66-B6AD-4BF0EF89FDA9@gmail.com> <CAESVnVpFmLuJkSG-znmOyRDh2evcEiv3ZXzQkhoet4r9hekM=A@mail.gmail.com> <1FC170E6-5207-45F3-8DF7-8B50787DCCA7@gmail.com> <CAESVnVro1_896Kc-1UjbGHixBbdVm2dc-uN0ycAB-pDeZrW4NA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] Improve (disable|enable)_functions #65386
From: ben.rubson@gmail.com (Ben RUBSON)


> On 10 Feb 2017, at 18:25, Sara Golemon <pollita@php.net> wrote:
>=20
> 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:
>>>=20
>>> PHP_INI_ENTRY("disable_functions", "", PHP_INI_SYSTEM, NULL)
>>=20
>> 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)
>>=20
> 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).
>=20
> 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.
>=20
>>> 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).
>>=20
>> Sounds like it would then require some dev to achieve this behaviour.
>> Would it however hurt requests performance ?
>>=20
> TL;DR - Yes.
>=20
> 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?
>>=20
>> Because one would certainly want to re-enable one of these functions =
in
>> one of its vhosts (or even globally in php.ini) :)
>>=20
> 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