Edit report at https://bugs.php.net/bug.php?id=69090&edit=1
ID: 69090
Comment by: sjon at hortensius dot net
Reported by: simon at ikanobori dot jp
Summary: add prefix/xor to cache keys/check permissions or
separate caches
Status: Analyzed
Type: Feature/Change Request
Package: opcache
Operating System: linux/debian
PHP Version: 5.6.5
Block user comment: N
Private report: N
New Comment:
jpauli, using separate pools does not fix this issue; the cache is maintained by the master process
that has access to all pools regardless of permissions of those pools.
Previous Comments:
------------------------------------------------------------------------
[2016-11-06 20:54:49] php-dev at coydogsoftware dot net
bjh438-git, thank you for your comments. I had previously read that article. The setup described
mitigates the security concerns I've outlined for one reason: It recommends disabling OPCache
completely.
Such a multi-user setup is generally recommended, but as I mentioned in my response to jpauli,
it's dangerous when combined with a single SHM cache with a simplistic hash keying scheme which
makes no attempt to segregate users.
My readings of php-internals archives suggest that OPCache was indeed meant to be usable in
multi-user setups so perhaps the maintainers simply haven't thought through the all
implications of the key scheme, though they have discussed its other shortcomimgs. I'm working
on a brief but more comprehensive advisory which I'll post here and on php-internals soon if we
don't get more meaningful engagement on this issue.
------------------------------------------------------------------------
[2016-11-06 17:27:01] bjh438-git at yahoo dot com
php-dev - would it not be best (at least when using fpm) to run each pool under a separate user /
group account as discussed here: https://www.digitalocean.com/community/tutorials/how-to-host-multiple-websites-securely-with-nginx-and-php-fpm-on-ubuntu-14-04
This would seem to satisfy the original suggestions earlier in the thread to leave as much as
possible to the OS level security controls.
I mention because I was wondering if your patches (which are warmly welcomed...I've been
posting on this issue for a while now on SF & SE) presume that these types of controls would
also be implemented or perhaps obviate them.
------------------------------------------------------------------------
[2016-11-04 20:11:41] php-dev at coydogsoftware dot net
I'll address jpauli's points:
Not everyone is using FPM. My patch fixes this problem on both FPM and apache2handler, where we can
separate users with mod_ruid2.
My experience with FPM is limited so I may be speaking out of turn, but when I tried separate FPM
pools with separate users, they were still forked from the same parent FPM master process. Correct
me if I'm wrong but the OPCache SHM segment is opened in this master process and inherited by
the pools as a file descriptor. The multi-user pools still share a single OPCache, and thus they
actually aid in bypassing file permissions, rather than fixing the problem.
I agree 100% with your points about relying on the lower stack to isolate vhosts and enforce
permissions, but the entire point of this bug report is that OPCache breaks this isolation in
real-world configurations since it uses a shared cache passed from Apache parent to children, or
from FPM master to pools.
You stated "Obviously, the OPCache SHM wouldn't be shared here" in a multi-pool
configuration. What would such a configuration look like? My testing shows the opposite to be true.
Perhaps you meant to suggest multiple FPM master daemons instead of multiple pools? If the OPCache
SHM can be initialized at the pool level instead of in the master process (I don't think this
is how it works today; I'd love to be proven wrong on this), this is great for FPM users but
does nothing for users of other SAPI's.
The big caveat in my testing is that most of it was done under cPanel. Both mod_ruid2/mod_php and
FPM have the shared OPCache problem under both EA3 and EA4. This is true for both PHP5 and PHP7. If
you think this is a problem with cPanel's apache2handler and FPM configurations then I can take
the issue up with cPanel, but I'd love to see how they could fix this for all SAPI's where
OPCache is useful. Clearly the problem isn't limited to cPanel though, based on the other users
commenting on this bug.
Hopefully this will clarify users' concerns with this bug; from your response I'm frankly
not sure you fully understand the problem we're reporting. I agree with "jeff at mcneill
dot io" that to isolate vhosts with PHP as it stands today, you'd need entirely separate
Apache parents (for apache2handler) or FPM master processes (not just multiple pools).
------------------------------------------------------------------------
[2016-11-04 17:11:34] jeff at mcneill dot io
The suggestion as one user per site would have to apply all the way across the stack. So Apache
would have to have a single user, and no multi-site, no virtual sites, no resource sharing at all?
This would mean full resources for each and every site, which would be extremely wasteful. I have a
client with four websites. Does the single client need four users? I have several clients but I want
to run all clients and all their sites with a single configuration. Apache can do this, PHP can do
this, therefore opcache should be able to support such a configuration.
------------------------------------------------------------------------
[2016-11-04 16:54:30] jpauli@php.net
Excuse me but...
Wouldn't it be safer, more reliable, less hackish ... to separate the PHP pools of the website
? One pool per site, each pool listening on one port for CGI requests.
I mean, we do know for sure, that PHP cannot replace the OS and the configuration to secure
webservers in a shared architecture (shared hosting).
We've tried things such as safe_mode, open_basedir etc... since the beginning, with no success.
Nowadays, with mature OS, mature stacks, and a mature FCGI handler (PHP-FPM), it is easy to build a
shared hosting architecture not relying on the PHP language itself to isolate the virtualhosts.
Security - of the filesystem here - is the matter of the OS , not PHP.
Why don't you create several PHP-FPM pools, and secure them with one Unix user per pool ?
Obviously, the OPCache SHM wouldn't be shared here, but that is not what you want : OPCache SHM
shouldn't be crossed against several websites.
One pool per website = one SHM per website = one unix user per website = we solved every low level
security problems, right ?
------------------------------------------------------------------------
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