[wp-trac] [WordPress Trac] #37680: PHP Warning: ini_get_all() has been disabled for security reasons

[WordPress Trac]

#37680: PHP Warning: ini_get_all() has been disabled for security reasons
----------------------------+--------------------
 Reporter:  dd32            |       Owner:
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  4.6.1
Component:  Bootstrap/Load  |     Version:  4.6
 Severity:  normal          |  Resolution:
 Keywords:  has-patch       |     Focuses:
----------------------------+--------------------

Old description:

> As reported in the Support Forums, WordPress 4.6 calls `ini_get_all()`
> which may be disabled on some hosts (possibly due to an old PHP 5.3.x
> security vulnerability).
>
> https://wordpress.org/support/topic/warning-ini_get_all-has-been-
> disabled-for-security-reasons
>
> This can be duplicated by adding `disable_functions = ini_get_all` to
> your `php.ini` file.
>
> Looking at our usage of the `ini_*` functions in core, we:
>  - sometimes silence warnings from `ini_set()` - usually early in the
> bootstrap, so I'm assuming from before `wp_debug_mode()` is called.
>  - never silence `ini_get()` calls.
>
> The current breakage on the affected hosts would be:
>  - A PHP Warning will be displayed on sites post-upgrade to 4.6.
>  - `wp_raise_memory_limit()` will fail to increase the memory limit,
> which may result in some admin pages not loading, or image uploads
> failing to create resized images.
>
> We should fix this to at least not present with a PHP Warning, although I
> recognise that almost any function could be in the `disable_plugin`
> setting, some (such as `phpinfo()` and `ini_*`) are historically much
> more likely to be there.
>
> See #32075 for introduction.

New description:

 As reported in the Support Forums, WordPress 4.6 calls `ini_get_all()`
 which may be disabled on some hosts (possibly due to an old PHP 5.3.x
 security vulnerability).

 https://wordpress.org/support/topic/warning-ini_get_all-has-been-disabled-
 for-security-reasons

 This can be duplicated by adding `disable_functions = ini_get_all` to your
 `php.ini` file.

 Looking at our usage of the `ini_*` functions in core, we:
  - sometimes silence warnings from `ini_set()` - usually early in the
 bootstrap, so I'm assuming from before `wp_debug_mode()` is called.
  - never silence `ini_get()` calls.

 The current breakage on the affected hosts would be:
  - A PHP Warning will be displayed on sites post-upgrade to 4.6.
  - `wp_raise_memory_limit()` will fail to increase the memory limit, which
 may result in some admin pages not loading, or image uploads failing to
 create resized images.
  - WSOD - Single-site installs will not increase their memory limit to
 40M, multisite will fail to increase to 64M, both of these could cause
 WSOD if the memory limit was set arbitrarily low and the site was running
 plugins which use a lot of memory.

 We should fix this to at least not present with a PHP Warning, although I
 recognise that almost any function could be in the `disable_plugin`
 setting, some (such as `phpinfo()` and `ini_*`) are historically much more
 likely to be there.

 See #32075 for introduction.

--

Comment (by dd32):

 I primarily see two main options:
  - Silence the PHP Warning [attachment:37680.diff]
  - Check the `disable_functions` list (as we do elsewhere for `phpinfo()`)
 [attachment:37680.2.diff]

 That then leaves the question of what to do when disabled, Do we return
 true anyway as a "We can't determine if it's changeable, so we're just
 assuming it probably is."? or do we just continue to return false as 4.6
 currently does?

 I've taken the angle that we should return true in the event we can't be
 sure, this may result in PHP warnings being emitted from `ini_set()`,
 however we already silence warnings on the `ini_set()`'s at least for the
 memory_limit (which is the only thing this function is used for
 currently). It's the `is_array()` block at the end of the function in both
 patches that's responsible for this behaviour.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/37680#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform