More secure opcache default configuration

[wattie]

First of all, you must disable by default opcache for PHP versions <5.6.30 and between 7.0.0 and 7.0.14. This is because of CVE-2015-8994. That security hole is making opcache totally unacceptable for shared hosting servers. Let me quote:

Child PHP processes inherit the SHM descriptor, using it to cache and retrieve compiled script bytecode ("opcode" in PHP jargon). Cache keys vary depending on configuration, but filename is a central key component, and compiled opcode can generally be run if a script's filename is known or can be guessed. Many common shared-hosting configurations change EUID in child processes to enforce privilege separation among hosted users (for example using mod_ruid2 for the Apache HTTP Server, or php-fpm user settings). In these scenarios, the default Zend OpCache behavior defeats script file permissions by sharing a single SHM cache among all child PHP processes. PHP scripts often contain sensitive information: Think of CMS configurations where reading or running another user's script usually means gaining privileges to the CMS database.

Next I propose an update to the default opcache configuration which comes with DirectAdmin. Currently it is:

opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
opcache.revalidate_freq=60
opcache.fast_shutdown=1
opcache.enable_cli=1
opcache.validate_permission=1

Please consider the following additions:

opcache.use_cwd=1 > this is the default anyway but "just in case" it must be absolutely always 1 for shared hosting. This causes the keys to be absolute path and not a relative one

opcache.revalidate_path=1 > not a fix but it's a hardening of security when symlinks are used. An issue can occur if user created symlinks and then change them.

opcache.enable_file_override=1 > speeds up loading when functions file_exists(), is_file() and is_readable() are used. It's a performance feature.

and a change:

opcache.revalidate_freq=0

Let me explain about the last one - it's pointless to have revalidate_freq higher than 0 when opcache.validate_permission is 1. The validation of permissions will do a disk operation anyway - you are almost not saving anything for not checking the timestamp since they are both in the filetable metadata anyway. On the other side it may have negative effect for users - they upload new version of their script and because of the caching... not seeing the results on the site. It's acceptable when I host all my files but I won't count it such when many users are using the server and almost nobody knows about that side effect of the caching. So briefly - not speeding up and causing confusion at the same time. It's not needed on shared hosting.

 

[ditto]

I would like to add a link to a article about some of this: https://ma.ttias.be/mitigating-phps-long-standing-issue-opcache-leaking-sensitive-data/

 

[Erulezz]

If I am correct these changes are now added in the config file;

cat opcache.ini 
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
[B]opcache.revalidate_freq=0[/B]
opcache.fast_shutdown=1
opcache.enable_cli=1
opcache.validate_permission=1
[B]opcache.use_cwd=1
opcache.revalidate_path=1
opcache.enable_file_override=1[/B]

Last time I checked (few weeks ago) I believe the last 3 lines were not there yet (Edit: opcache config file has been changed on 5/10, 5 oct). Not trying to bump old threads but I thought this might be useful to bring under attention, especially the opcache.revalidate_freq change:

0 will result in OPcache checking for updates on every request.

Isn't this going to slow things down? Why has this been changed from 60 to 0? Regarding the max files value, why not use explicit values like described in the config?

The actual value used will be the first number in the set of prime numbers { 223, 463, 983, 1979, 3907, 7963, 16229, 32531, 65407, 130987 } that is greater than or equal to the configured value.

The default is also changed to 10000.

 

[wattie]

Isn't this going to slow things down? Why has this been changed from 60 to 0? Regarding the max files value, why not use explicit values like described in the config?

Read the end of the first post in the thread.

 

[Tristan]

Great idea!