Doc #71340 [Com]: php_admin_value[error_reporting] in fpm/apache conf can be bypassed in user code
| From: | info at getpagespeed dot com | 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