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

From: Date: Mon, 18 Jun 2018 04:11:58 +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-15787@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: etron at gmail 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: https://www.getpagespeed.com/server-setup/security/php-security-disable-error_reporting-now -- Amazing. Like this article implies error_reporting is bad, lets disable functions to delete|update|rename|create a file|folder, as hey, it can users data (based on programmers logic).. Previous Comments: ------------------------------------------------------------------------ [2018-06-18 03:57:59] etron at gmail dot com I can only say that is a shame that core php devs are totally unaware on how useful this feature is in general and how is used from an hosting provider point of view. -- In another news, Apparently some core-developer thought "register_globals" as a useful function. Its *idiots* like you make a php a joke. ------------------------------------------------------------------------ [2018-06-18 03:53:51] etron at gmail dot com 1) php has ever worked that way, no one had never had problems about it -- Remember "fractal of bad design" 5) we are not switching to php7 because of this -- Yeah.. dont bother, your clients will find better hosting providers. ------------------------------------------------------------------------ [2018-06-16 20:07:41] nikic@php.net As this issue is clearly important to you, I would recommend to start a discussion about this on the PHP internals mailing list. Discussion in a broader context may yield a more favorable outcome. ------------------------------------------------------------------------ [2018-06-16 19:41:23] nikic@php.net 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: ðPó > ®­hÙB&féŒÿ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. ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ 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 (#15787) next »