Edit report at https://bugs.php.net/bug.php?id=69090&edit=1
ID: 69090
Comment by: danieleckid at gmail dot com
Reported by: simon at ikanobori dot jp
Summary: add prefix/xor to cache keys/check permissions or
separate caches
Status: Closed
Type: Feature/Change Request
Package: opcache
Operating System: linux/debian
PHP Version: 5.6.5
Assigned To: dmitry
Block user comment: N
Private report: N
New Comment:
I would to update this bug with releated issue.
# php-fpm -v
PHP 7.2.10 (fpm-fcgi) (built: Oct 3 2018 08:52:25)
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
with Zend OPcache v7.2.10, Copyright (c) 1999-2018, by Zend Technologies
# uname -a
FreeBSD websrv1 11.2-RELEASE-p4 FreeBSD 11.2-RELEASE-p4 #0: Thu Sep 27
08:16:24 UTC 2018
root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
php-fpm pools:
[aaa]
user = aaa
group = nobody
listen.owner = aaa
listen.group = www
listen.mode = 660
listen = /var/sockets/php72-aaa.sock
chroot = /home/aaa
(...)
[bbb]
user = bbb
group = nobody
listen.owner = bbb
listen.group = www
listen.mode = 660
listen = /var/sockets/php72-bbb.sock
chroot = /home/bbb
(...)
php.ini quotation:
(...)
[opcache]
opcache.use_cwd = 1
opcache.validate_permission = 1
opcache.validate_root = 1
echo "some small php code" > /home/aaa/public_html/index.php
chown aaa /home/aaa/public_html/index.php
echo "some huge php code" > /home/bbb/public_html/index.php
chown bbb /home/bbb/public_html/index.php
Even with these above new settings opcache caches only one sample of
index.php from two totals.
When visiting website of user aaa then index.php of this user is located in opcache cache. When
visiting website of user bbb only index.php of bbb is located in the cache instead.
We are never seeing these two files cached same time although these are
two different files. These has two different non-chrooted paths and different persmission (owner).
We have found this issue looking at list of cached files as seen on
opcache-status-master/opcache.php. Even if file list is innacurate we had compared also used/free
memory and that looks like only one file is cached same time.
We haven't found crosscache problem nor other security problem. Just no cache profit when
chrooted paths and names of files are the same (which is common and expected in multiuser chroot
environment)
Previous Comments:
------------------------------------------------------------------------
[2016-12-16 04:01:22] me at anatoli dot ws
The issue in question appears to be fixed, thanks Dmitry for resolving this 2yo security and
stability problem. Nevertheless, IMO the current solution looks more like a workaround for a larger
problem: there's complex code (for which multiple bugs are fixed in half of the releases) that
runs outside the chroot environment with complete visibility of the entire filesystem, making it a
perfect escape route (which was actually demonstrated with the current bug).
IMO, the appropriate fix would be to initialize everything that could access the filesystem
(including internal functionality & all plug-ins) AFTER performing chroot. Only the logic
responsible for loading of the configs, libraries and modules should be placed in the pre-chroot
portion of the daemon (to avoid placing their files in the chroot environment), but NOT their
parsing (for the per-pool configs), initialization (for the modules) and management, which should be
performed in the isolated chrooted environments, a separate instance for each chrooted pool.
If the current logic is to save some memory that could be shared between the chrooted pools, I do
believe that security should not be sacrificed for performance or lower resource usage, especially
nowadays with so cheap hardware.
PHP devs, please let me know if it's appropriate to open a new bug (type: security) for
tracking this change or if this one should be reopened, or if you consider this issue has no merit
to expect its implementation some day.
------------------------------------------------------------------------
[2016-11-22 13:14:10] krakjoe@php.net
Automatic comment on behalf of dmitry@zend.com
Revision: http://git.php.net/?p=php-src.git;a=commit;h=ecba563f2fa1e027ea91b9ee0d50611273852995
Log: Fixed bug #69090 (check cached files permissions)
------------------------------------------------------------------------
[2016-11-16 09:59:39] dmitry@php.net
Automatic comment on behalf of dmitry@zend.com
Revision: http://git.php.net/?p=php-src.git;a=commit;h=ecba563f2fa1e027ea91b9ee0d50611273852995
Log: Fixed bug #69090 (check cached files permissions)
------------------------------------------------------------------------
[2016-11-16 09:58:45] dmitry@php.net
Automatic comment on behalf of dmitry@zend.com
Revision: http://git.php.net/?p=php-src.git;a=commit;h=ecba563f2fa1e027ea91b9ee0d50611273852995
Log: Fixed bug #69090 (check cached files permissions)
------------------------------------------------------------------------
[2016-11-15 15:37:58] dmitry@php.net
The following patch has been added/updated:
Patch Name: bug69090.diff
Revision: 1479224278
URL: https://bugs.php.net/patch-display.php?bug=69090&patch=bug69090.diff&revision=1479224278
------------------------------------------------------------------------
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=69090
--
Edit this bug report at https://bugs.php.net/bug.php?id=69090&edit=1