Edit report at https://bugs.php.net/bug.php?id=71340&edit=1
ID: 71340
Comment by: admin at inwebse 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: Bug
Package: PHP options/info functions
Operating System: Any
PHP Version: 7.0
Block user comment: N
Private report: N
New Comment:
Any news?
Previous Comments:
------------------------------------------------------------------------
[2018-05-06 16:06:29] php at alternize dot com
for anyone who thinks "php_admin_value[error_reporting]" should not be immutable: nobody
is forced to use this. if you want to allow apps/users to change the error level, use
"php_value[error_reporting]" and you're good.
whoever sets "php_admin_value[error_reporting]" certainly has her/his reasons - there
*are* valid reasons for doing so, some outlined in this bug's comments.
------------------------------------------------------------------------
[2018-05-06 15:45:17] spam2 at rhsoft dot net
@ operator has nothing to do with a ini-value
hell what is the problem simply ignore ini_set() for values or flags set with php_admin_* which
should have no other runtime impact or even offer optimizations because its known not to change
------------------------------------------------------------------------
[2018-05-06 15:33:15] gpointorama at gmail dot com
Instead of starting ethical discussions about how php error design works please keep in mind:
1) php has ever worked that way, no one had never had problems about it
2) between php 5 and 7 has been introduced a backward incompatible change, without documenting it
3) shops that do php hosting want to be like php itself "do the right thing" in a
pragmatic way,
if our clients/or use code from third parties that do messy things about error_reporting we want
all will work anyway in most cases without touching
their code, for example wordpress and plugins
we can't afford and it's a also bad for all if who hosts had review all the code of our
clients/third parties plugins etc...while switching from php 5 to 7
also keep in mind that, the already slow adoption of php 7, for hosting providers will slow more
before php 7 we had the option to "php_admin_value[error_reporting] = E_ALL & ~E_NOTICE
& ~E_DEPRECATED & ~E_WARNING & ~E_STRICT" and all was good in case of problems
4) if php want to introduce a new better way/design to handle errors a new separate mode can be
added but should be optional until all php code/devs in the
word will know about that
5) we are not switching to php7 because of this
------------------------------------------------------------------------
[2018-05-06 15:07:35] nikic@php.net
The problem I see is that error_reporting is a somewhat more fundamental configuration option with
direct language integration. If you take your premise that php_admin_value should affect the
error_reporting() function one step further, you could also argue that the @ operator should become
ineffective if php_admin_value[error_reporting] is used (which I think would be quite the
disaster...)
------------------------------------------------------------------------
[2018-05-06 15:06:52] requinix@php.net
The thing is, error_reporting is more than just an INI value. It has a much larger impact on PHP at
runtime than options like include_path do. And while include_path probably only needs to be set once
or twice in code, during an initialization phase, it's perfectly reasonable to change the
error_reporting value at any time in any number of circumstances.
If no changes to the error reporting level are allowed at all, what about the @ operator? Should
that be blocked because it temporarily suppresses the level entirely?
Perhaps a php_admin_value for error_reporting should be treated as more than just an immutable
number. Say, as a bitmask that is always ORed with a desired new value? That would guarantee errors
of a certain type are always visible while allowing code and libraries to opt into other types. I
think that would be a more common use case than needing to ensure a maximum level (ANDing) so code
would only be able to turn off error types - which is probably needed for specific situations that
could be addressed with careful use of @.
------------------------------------------------------------------------
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