Bug #74182 [Opn]: Unsafe default for opcache.validate_permission

From: Date: Tue, 28 Feb 2017 16:42:29 +0000
Subject: Bug #74182 [Opn]: Unsafe default for opcache.validate_permission
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-207608@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=74182&edit=1 ID: 74182 User updated by: michael at orlitzky dot com Reported by: michael at orlitzky dot com Summary: Unsafe default for opcache.validate_permission Status: Open Type: Bug Package: opcache PHP Version: Irrelevant Block user comment: N Private report: N New Comment: > 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. Previous Comments: ------------------------------------------------------------------------ [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) ------------------------------------------------------------------------ [2017-02-28 15:23:57] michael at orlitzky dot com Description: ------------ The opcache.validate_permission setting was introduced to fix a vulnerability (now CVE-2015-8994) in shared hosting environments. However, it defaults to "0", meaning it's off. The performance impact of the additional check should not be cataclysmic, and shared hosting is almost synonymous with PHP. As a result, I think the default should be opcache.validate_permission=1. Reference: http://www.openwall.com/lists/oss-security/2017/02/27/4 ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=74182&edit=1

« previous php.bugs (#207608) next »