Is "All PHP Options + OpCache" option safe to use?
-
OpCache would require some type of persistent PHP handler, like php-fpm or DSO. It won't work with suPHP. As for the security of OpCache, I would think using file-based OpCaching would be more secure. But cPanel's opcache module does not allow file-based OpCache. A request to enable file-based OpCache has been made in the cPanel feature request section: Enable file-based OpCache for PHP 7.0/7.1 But it is stuck in request purgatory. 0 -
Hello, You may also find the discussion on the following thread helpful: Configuring Opcache across multiple accounts Thank you. 0 -
Hello @sparek-3 Why do you think file-based caching is more secure? I think the opposite, if the directory is not well configured against write, file-based caching is less secure (But I'm not an expert on the subject). In performance yes, it should bring improvements when the opcache restarts. You may also find the discussion on the following thread helpful: Configuring Opcache across multiple accounts
Hello @cPanelMichael Sorry for the lack of knowledge on this subject. I read everything, but I still can not make sure the profile is safe for shared hosting. I imagine that anyone who created this profile would not do it in a way that could not be used with shared hosting, which is the purpose of cPanel. Or at least without warning of possible security problems. But I would like to be sure and hear from your team if I can trust on this profile.0 -
Reading the documentation and characteristics of this profile, I can say that it uses php-fpm, suphp and seuexec. What is recommended for it to be secure in shared hosting. But I'd love to hear this from you guys! 0 -
Using memory objects in OpCache is going to mean that anyone using PHP from that master process would have access to those objects. So unless you are using a separate master pool for each VirtualHost (which would be a lot of master pools) then any VirtualHost would have access to OpCache objects from other VirtualHosts. With file-based OpCaching, those objects are written into a directory that only the owner of that VirtualHost can read. So no other users would be able to read the objects from that directory. I suppose VirtualHosts that are owned by the same user would have read access, but I really don't think that would be a huge issue. Some of the issues with OpCache memory objects can be found at: PHP :: Bug #67481 :: Opcache uses wrong file from cache I would also encourage you to take a look at the opcache_get_status() function when using OpCache. There is also some discussion on this topic at SOLVED - Zend OPcache and PHP-FPM It's been a while since I've looked at all of this. Looking through some of those posts, apparently it's been close to a year. I pretty much abandoned all OpCache work because of these issues. 0 -
Hello @sparek-3 , The opcache_get_status() function is easy to solve just by configuring opcache.restrict_api in php.ini. Maybe I'm missing something here. I was not able to reproduce this bug in cPanel version 64. I tried to collide two php files in different accounts using php-fpm, but it did not work. The only way I would imagine anyone could inject code into other accounts or read php files from other accounts would be if there were file collisions. Which does not seem to be the case these days. Make sure you are using opcache.use_cwd as true. I would still like to hear from the staff who developed this profile if it is safe to use on shared hosting. My biggest concern is that someone can read or execute code with user nobody. 0 -
Another way to use separate opcache would be to spawn separate php-fpm master for each user. A working solution on cPanel (centos7-systemd) is below autom8n.com/howtos/systemd.html#spawning-multiple-php-fpm-masters-using-systemd-socket-activation This would also allow setting resource limits for php per user in systemd The only downside I see in this is that since the master process run as user, it cannot be chrooted which is otherwise possible Also, You can do with current cPanel setup : autom8n.com/xtendweb/PHP.html#zendopcache-and-security-considerations-on-php-fpm-single-master-setup 0 -
Thanks for the suggestions, but I want to use the default cPanel profile. Disregarding the "possible" collision of php files (bug that I was not able to reproduce), is it safe to use this profile? 0 -
Hello, Here's a quote from a previous internal case you may find helpful: Opcache w/FPM is secure. OPCache uses shared memory to cache compiled PHP "opcode" between HTTP requests for reuse. A single shared memory object is opened and initialized in a parent process, and child processes inherit its file descriptor. Due to this design, OPCache is intended for use with a SAPI with a persistent parent process, for example php-fpm with its master process, or apache2handler where initialization occurs in the Apache parent process.
However, note that "safe" is a very broad term and related to more than just the options enabled by default in an EasyApache 4 build profile. The following document may also provide you with some useful information: PHP Security Concepts - cPanel Knowledge Base - cPanel Documentation Thank you.0 -
Hello @cPanelMichael , I studied a lot and did my own tests. And adding what I've found, and the answers I've received here, I believe that opcache is safe for use in shared hosting as long as you take some cares. Thanks for the answer. And the documentation sent was very helpful! 0 -
@Rodrigo Gomes I know your post was last year, is it possible to share what steps you took regarding security. This would help a lot (and be appreciated) - Thank you. 0 -
@Rodrigo Gomes / "@ALL" And 2 years later the next one is coming - me..... Would really be informative to talk about 0
Please sign in to leave a comment.
Comments
12 comments