Doc #71340 [Ana]: php_admin_value[error_reporting] in fpm/apache conf can be bypassed in user code

Edit report at https://bugs.php.net/bug.php?id=71340&edit=1 ID: 71340 Updated by: nikic@php.net Reported by: gpointorama at gmail dot com Summary: php_admin_value[error_reporting] in fpm/apache conf can be bypassed in user code Status: Analyzed Type: Documentation Problem Package: PHP options/info functions Operating System: Any PHP Version: 7.0 Block user comment: N Private report: N New Comment: Based on @philip's request I'm taking another look at this. However, the resolution is unchanged. > * What are the possible workarounds for this? Ideally ones that don't involve > patching PHP. > > For example, maybe adding "disable_functions = error_reporting" but that'd add > > a bunch of E_WARNING's. Not ideal, are there others? To clarify my position: This is exactly the intended outcome. In my opinion, and the opinion of all other developers I talked to regarding this issue, a hosting provider should not have the possibility to enforce an error_reporting level for the application. From the comments in this bug report, it is apparent that this functionality has been used by certain hosting providers to disable error_reporting for notices and deprecation warnings. Historically, the willingness of developers to ignore such "low level" diagnostics, which nonetheless may indicate severe programming errors, has been an issue for the PHP programming language. Perpetuating this kind of development practice by not only disabling notices by default, but going so far as to prevent applications from explicitly re-enabling them, is damaging to the overall PHP community. While we cannot prevent you from patching PHP, or from writing an extension that intercepts the error reporting mechanism, we can at least remove dedicated support for this functionality. > This isn't a documentation bug as recently marked here. It is a big fat SECURITY BUG. > The ability for override whatever logging level with NONE has an immense security > implication... > See my notes about it here: > https://www.getpagespeed.com/server-setup/security/php-security-disable-error_reporting-now > The current wave of malware targeting PHP 7 effectively uses this bug to hide itself. It's nice that you have friendly malware that generates lots of errors that make it easy to detect, but that's certainly not a characteristic you can rely on. Malware could just as easily be completely error-free code, and if this is your only way of detecting it, I'm afraid to say that it is likely not particularly effective. Previous Comments: ------------------------------------------------------------------------ [2018-06-14 10:02:40] info at getpagespeed dot com This isn't a documentation bug as recently marked here. It is a big fat SECURITY BUG. The ability for override whatever logging level with NONE has an immense security implication... See my notes about it here: https://www.getpagespeed.com/server-setup/security/php-security-disable-error_reporting-now The current wave of malware targeting PHP 7 effectively uses this bug to hide itself. ------------------------------------------------------------------------ [2018-06-12 16:33:07] admin at inwebse dot com > For example, maybe adding "disable_functions = error_reporting" but that'd add a > bunch of E_WARNING's. Not ideal, are there others? Very bad idea. For example, Roundcube with "disable_functions = error_reporting" doesn't work... > For clarity, does this PHP 7 change allow error_reporting(foo) but continue to disallow > ini_set("error_reporting", foo) with php_admin_*? If so then that'd be weird and > likely unintentional, right? Code: echo "php_admin_value: " . ini_get("error_reporting") . "<br>"; ini_set("error_reporting", 8); echo "ini_set: " . ini_get("error_reporting") . "<br>"; error_reporting(8); echo "error_reporting: " . ini_get("error_reporting") . "<br>"; Return: php_admin_value: 2 ini_set: 2 error_reporting: 8 But there must be all "2". PHP 7.2.6 ------------------------------------------------------------------------ [2018-06-08 18:52:40] philip@php.net A few thoughts from the peanut gallery: * What are the possible workarounds for this? Ideally ones that don't involve patching PHP. For example, maybe adding "disable_functions = error_reporting" but that'd add a bunch of E_WARNING's. Not ideal, are there others? * For clarity, does this PHP 7 change allow error_reporting(foo) but continue to disallow ini_set("error_reporting", foo) with php_admin_*? If so then that'd be weird and likely unintentional, right? ------------------------------------------------------------------------ [2018-06-06 15:18:00] php at alternize dot com I amazed that the "new" behavior would be considered the desired one, as that makes absolutely no sense. there is *no other way* to enforce a consistent error logging when this backwards incompatible bug is kept. on the other way, nobody *was forced to use* "php_admin_value[error_reporting]": if you did not want an immutable error_reporting, use "php_value[error_reporting]" in your fpm config or "error_reporting" in php.ini or use the error_reporting function. "php_admin_value[error_reporting]" wasn't a default setting either, and those that used it, knew why and what it would mean. this takes away a really useful feature from those that had their reasons to use it, without any gain to the php code in general. there has been no reason shown in this bug reports comment what the php world has gained by introducing the backward breaking change. ------------------------------------------------------------------------ [2018-06-06 15:00:26] admin at inwebse dot com I have a lot of websites and i maintain them. And i want to have centralized point where i can see problems from all of my sites. I want to run journalctl --follow --unit=php-fpm.service for tracking errors for all of my sites. Not going to every site for modifying error_reporting or error_log (syslog) or something else. Maybe this is not a best solution for developers, who wants to have a full control, but a best solution for hostings / sysops / etc. But now we are dropped from a boat. That's very sad... ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=71340 -- Edit this bug report at https://bugs.php.net/bug.php?id=71340&edit=1