> Many common shared hosting configurations change EUID in child 
> processes to enforce privilege separation among hosted users. 
> In these scenarios, default Zend OpCache behavior defeats 
> script file permissions by sharing
> a single SHM cache among all child PHP processes

frankly i don't get the whole problem and list discussion

if you want user separation you are normally supposed to start seperate master instances be it FPM-ppols or sepearted httpd-instances in case of mod_php and the childprocesses of each pool are supposed to share the SHM cache

without sharing the cache between children you end in a desaster as realpath_cache does for a decade now: https://bugs.php.net/bug.php?id=73888 (not enough that you need to patch the php source that it get enabled at all wehn using open_basedir while you are sure that all link/symlink functions are forbidden and so there is no security problem)

> opcache.validate_permission (default "0")
> Leads OPcache to check file readability on each access 
> to cached file. This directive should be enabled in shared 
> hosting environment, when few users (PHP-FPM pools) 
> reuse the common OPcache shared memory

"The performance impact of the additional check should not be cataclysmic"

no - it is not - it defeats "opcache.validate_timestamps" with a high "opcache.revalidate_freq" while the whole purpose is to minimize disk operations as much as possible

enable that by default just because there could be someone with a not well thought configuration is not justified, anyways, thans for the pointer so that i put "opcache.validate_permission = 0" in configurations if someone later decides to change the default

> if you want user separation you are normally supposed to
> start seperate master instances be it FPM-ppols or sepearted
> httpd-instances in case of mod_php and the childprocesses of
> each pool are supposed to share the SHM cache

Here's how this affects us: we have a separate system user for each website. In Apache, mpm_itk is used to run each virtual host as that dedicated user, sharing one mod_php. The end result is that the PHP code runs as a dedicated user on each website that uses PHP. However, there is one global cache that all users have access to.

No one is suggesting that the global cache be eliminated. Only that filesystem permissions should not be bypassed when the cache is turned on.

well, and i know setups where you have undret httpd instances with mod_php, each running as seperate user and the additional stat call is just a surprising increase in IO operations when teh default changes

would you set "open_basedir" in your setup with the shared mod_php for each virtual host one could not bypass that way because openbase_dir is validated within opcache and don't need disk IO to work

without you rely completly in filesystem permsissions and i doubt thats eonugh in the real world where users/customers careless set 0666 or even 0777 on their uploaded scripts

> would you set "open_basedir" in your setup with the shared mod_php
> for each virtual host one could not bypass that way because
> openbase_dir is validated within opcache and don't need disk IO
> to work

I've already done that on our servers, but I've also already set opcache.validate_permission=1. There's no doubt that somebody who knows what he's doing can set things up safely. The only question is whether the default configuration should be a little bit faster or a little bit more secure.

My take is that everyone needs their installation to be secure, but not everyone needs the utmost performance. The sites where things truly need to be fast will have administrators that know what they're doing and can enable optimizations like opcache.validate_permission=0. On the other hand, almost nobody knows about the setting, so the nearly-everybody who would prefer the secure mode will not have it set correctly.

Interesting topic!  But I don't think it makes any sense to keep
this ticket open after four years of inactivity, so I'm going to
suspend it.  If anybody is still interested in having the default
value of this option to change, please consider to pursue the RFC
process[1].  Maybe the first step to bring that forward to the
internals mailing list would be sufficient.

FWIW, personally, I don't think that it is a good idea to share
OPcache instances for different Websites, let alone for different
users, regardless of possible mitigations in PHP; if there is a
memory management bug, others may be able to read sensitive
information…

[1] <https://wiki.php.net/rfc/howto>