Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98278
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.44 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
In-Reply-To: <CAESVnVpFmLuJkSG-znmOyRDh2evcEiv3ZXzQkhoet4r9hekM=A@mail.gmail.com>
Date: Fri, 10 Feb 2017 10:02:27 +0100
Content-Transfer-Encoding: quoted-printable
Message-ID: <1FC170E6-5207-45F3-8DF7-8B50787DCCA7@gmail.com>
References: <4CD4DCCC-6643-4A66-B6AD-4BF0EF89FDA9@gmail.com> <CAESVnVpFmLuJkSG-znmOyRDh2evcEiv3ZXzQkhoet4r9hekM=A@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 09 Feb 2017, at 18:12, Sara Golemon <pollita@php.net> wrote:

Thank you very much Sara for your feedback !

> On Thu, Jan 19, 2017 at 6:18 AM, Ben RUBSON <ben.rubson@gmail.com> =
wrote:
>> As proposed by cmb (thank you !), I open a discussion regarding req =
#65386 :
>> https://bugs.php.net/bug.php?id=3D65386
>>=20
>> It summarizes requests around disable_functions directive :
>> - modification of disable_functions to be a PHP_INI_SYSTEM directive =
;
>>=20
> Could you clarify? `disable_functions` *IS* a PHP_INI_SYSTEM =
directive:
>=20
> 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)

>> - implementation of enable_functions as a PHP_INI_SYSTEM directive ;
>>=20
> I'm not a big fan of a whitelist for weakening/overriding a blacklist =
setting.

(*)

> 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 ?

> func->handler =3D ZEND_FN(display_disabled_function);
>=20
>=20
>> - support of wildcards in these 2 directives.
>>=20
> I could potentially get down with wildcards.  It's way easier to
> exhaustively cover an entire class of functions,

Yep, as it's quite hard to maintain an exhaustive list of functions...

> 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) :)

> I understand this part makes more sense with the `enable_functions`
> idea, but... see above.

Yes, this would really be convenient :
- in php.ini           : disable_functions =3D *socket*
- in a "trusted" vhost : enable_functions =3D stream_socket_client

And as only the server administrator can tune these parameters, there is
no weakening (*) risk :)

Thank you !

Ben=