Bug->Req #74182 [Opn->Sus]: Unsafe default for opcache.validate_permission

Edit report at https://bugs.php.net/bug.php?id=74182&edit=1 ID: 74182 Updated by: cmb@php.net Reported by: michael at orlitzky dot com Summary: Unsafe default for opcache.validate_permission -Status: Open +Status: Suspended -Type: Bug +Type: Feature/Change Request Package: opcache PHP Version: Irrelevant Block user comment: N Private report: N New Comment: 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> Previous Comments: ------------------------------------------------------------------------ [2017-02-28 17:06:23] michael at orlitzky dot com > 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. ------------------------------------------------------------------------ [2017-02-28 16:53:30] spam2 at rhsoft dot net 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 ------------------------------------------------------------------------ [2017-02-28 16:42:25] michael at orlitzky dot com > 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. ------------------------------------------------------------------------ [2017-02-28 16:41:11] spam2 at rhsoft dot net > 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 ------------------------------------------------------------------------ [2017-02-28 16:30:50] spam2 at rhsoft dot net > 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) ------------------------------------------------------------------------ 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=74182 -- Edit this bug report at https://bugs.php.net/bug.php?id=74182&edit=1