> On 09 Feb 2017, at 18:12, Sara Golemon <poll...@php.net> wrote: Thank you very much Sara for your feedback !
> On Thu, Jan 19, 2017 at 6:18 AM, Ben RUBSON <ben.rub...@gmail.com> wrote: >> As proposed by cmb (thank you !), I open a discussion regarding req #65386 : >> https://bugs.php.net/bug.php?id=65386 >> >> It summarizes requests around disable_functions directive : >> - modification of disable_functions to be a PHP_INI_SYSTEM directive ; >> > 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) >> - implementation of enable_functions as a PHP_INI_SYSTEM directive ; >> > 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 = ZEND_FN(display_disabled_function); > > >> - support of wildcards in these 2 directives. >> > 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 = *socket* - in a "trusted" vhost : enable_functions = stream_socket_client And as only the server administrator can tune these parameters, there is no weakening (*) risk :) Thank you ! Ben -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
