|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #79560 Bypass open_basedir with opcache
Submitted: 2020-05-03 08:16 UTC Modified: 2020-06-08 05:21 UTC
From: remi dot pellerin at ens-lyon dot fr Assigned:
Status: Open Package: opcache
PHP Version: Irrelevant OS: Debian 10.3
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Bug Type:
From: remi dot pellerin at ens-lyon dot fr
New email:
PHP Version: OS:


 [2020-05-03 08:16 UTC] remi dot pellerin at ens-lyon dot fr
I use the 7.3.14-1 package from debian stable repository (built: 16 Feb 2020).
I have opcache enabled with common settings taken from the doc:

opcache.enable_cli=0 (This I believe we do not care)

I've got several apache virtual host and each has a specific open_basedir. However, I can bypass the open_basedir restriction if I do a require on a file used very often (typically, defines.php where I store mysql password !). The issue disappear when I restart apache2/php: that is, I have an "open_basedir restriction in effect" message. In my opinion this is because the cache of opcache is empty. Then, after loading a few pages, I can require the file despite it's not in my open_basedir.

NB : It may just be that it is not really a security issue and that any admin with several websites shouldn't use opcache. But in that case, I think the doc should mention this (it's not the case yet).

Test script:
/* My open_basedir is /var/www/foo */

require('/var/www/bar/passwords.php');//Works if password.php is in opcache table


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2020-05-04 13:49 UTC]
-Status: Open +Status: Verified
 [2020-05-04 13:49 UTC]
I can reproduce the segfault via cli server:

#0  0x0000555555da20e6 in _zend_is_inconsistent (ht=0x0, 
    file=0x55555664f608 "/home/nikic/php-7.4/Zend/zend_hash.c", line=2045)
    at /home/nikic/php-7.4/Zend/zend_hash.c:54
#1  0x0000555555da8abb in zend_array_dup (source=0x0) at /home/nikic/php-7.4/Zend/zend_hash.c:2045
#2  0x0000555555e6131d in ZEND_BIND_STATIC_SPEC_CV_UNUSED_HANDLER ()
    at /home/nikic/php-7.4/Zend/zend_vm_execute.h:46850
#3  0x0000555555e6c0a0 in execute_ex (ex=0x7fffeb615020)
    at /home/nikic/php-7.4/Zend/zend_vm_execute.h:57622
#4  0x0000555555e6c594 in zend_execute (op_array=0x7fffeb603100, return_value=0x0)
    at /home/nikic/php-7.4/Zend/zend_vm_execute.h:57922

Static variables are NULL.
 [2020-05-04 14:07 UTC]
-Status: Verified +Status: Open
 [2020-05-04 14:07 UTC]
Sorry, I commented on the wrong bug.
 [2020-05-19 14:21 UTC]
-Assigned To: +Assigned To: stas
 [2020-05-19 14:21 UTC]
Indeed, that does not look like a security issue on our side.
Actually, there is no point in sharing OPcache instances across
unrelated apps, let alone Websites.

Improving the OPcache docs on how it works with different SAPIs
(and different OSs) would be reasonable.
 [2020-06-08 05:21 UTC]
-Status: Assigned +Status: Open -Type: Security +Type: Documentation Problem -Assigned To: stas +Assigned To:
 [2020-06-08 05:21 UTC]
I think it makes sense to document that if you worry about apps seeing each other's files you may want to run them on different PHP/Opcache setups.
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Wed Nov 29 21:01:29 2023 UTC