Re: Removing support for the disable_classes INI setting
| From: | G. P. B. | Date: | Mon, 14 Aug 2023 20:11:54 +0000 |
| Subject: | Re: Removing support for the disable_classes INI setting | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-120902@lists.php.net to get a copy of this message | ||
On Mon, 14 Aug 2023 at 20:04, Juliette Reinders Folmer <
php-internals_nospam@adviesenzo.nl> wrote:
> Hi George,
>
> For what its worth: in my experience, the
disable_classes and
> disable_functions ini directives are mostly used by hosting
> companies
> providing shared/virtual host environments and, most often for those
> environments, not editable by their users via a control panel or nor do
> these users have (edit) access to the php.ini file.
>
To be clear, I have no intention of deprecating or removing
disable_functions.
This INI setting works very well and does not cause any issue within the
engine.
[...]
>
> Would deprecating it in PHP 8.3 and removing it in PHP 9.0 be an option ?
>
One option is to "keep" the INI setting, but have it basically do nothing.
Is this what you had in mind?
> As for the lack of bug reports - the typical type of end users using
> those hosts will not know to report these type of issues to PHP (or even
> be able to properly identify the issue). Instead they will complain
> extensively to whatever open source project (read: WordPress) they are
> running on the shared hosting without providing enough information for
> the open source maintainers to even begin to identify the actual
> issue... ;-)
>
On a minimal build of PHP, with only the mandatory extensions enabled,
there are 148 classes/interfaces/traits defined. [1]
Other than the SPL ones (and even then), disabling any of these classes
will cause issues within the engine.
Moreover, the SPL ones are not a security concern.
Therefore, any other class that can be disabled must come from an extension
that can be disabled altogether. And "disabling" a class from an extension
without disabling said extension will render it useless anyway.
If a hosting provided is concerned about an extension, then it should not
enable it in the first place. Not break it ad hoc.
Considering the above, I cannot see how this functionality was ever useful.
This is in stark contrast to disable_functions, which can be used to
selectively remove functionality of an extension without breaking it
overall.
George P. Banyard
[1] https://gist.github.com/Girgias/63d55ba1e50b580412b004046daed02b