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

From: Date: Thu, 14 Jun 2018 10:02:43 +0000
Subject: Doc #71340 [Com]: php_admin_value[error_reporting] in fpm/apache conf can be bypassed in user code
References: 1  Groups: php.doc.bugs 
Request: Send a blank email to doc-bugs+get-15768@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=71340&edit=1 ID: 71340 Comment by: info at getpagespeed dot com 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: 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. Previous Comments: ------------------------------------------------------------------------ [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... ------------------------------------------------------------------------ [2018-06-06 14:55:38] gpointorama at gmail dot com If we want to talk about a clean and elegant way to fix this mess with error handling in php then i can propose an error_reporting(E_ALL){... php code here ...} block to make clear and obvious the scope of the error_reporting settings....but that's another matter... ------------------------------------------------------------------------ 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

« previous php.doc.bugs (#15768) next »