Failure to apply permissions to files with PHP file extension in GNU/Linux

[Ravenman]

Description

Permissions applied to files with PHP extension from the operating system are not applied immediately, it is necessary to restart the operating system.

1. Create one file called anything.php with 644 or 755 permissions and put it in any web server root directory.
2. Read the file anything.php from your web browser. (We can see the file content).
3. Change the permissions file to 000 and refresh your web browser (We can still see the file content).
4. After restarting the operating system, it is not possible to see the contents of the file.
5. Change the permissions file to 655 or 755 and refresh your web browser (We can see the file content).
6. Repeat the step 3 and you will get the same result.

This occurs in versions 7.4.x through 8.x.x versions and only with files with PHP file extension. These tests were performed on Rocky Linux 8.x and Rocky Linux 9.x, Alma Linux 9.1 and Ubuntu Server 20.04 with Apache and NGINX web servers installed. Only works properly in PHP versions 7.2 and 7.3

PHP Version

PHP 8.2.4

Operating System

Rocky Linux 8.x and Rocky Linux 9.x, Alma Linux 9.1 and Ubuntu Server 20.04

[nielsdos]

I just checked this. This is because opcache caches the bytecode of the file, so the file isn't actually read again from disk.
And apparantly, the revalidation frequency code doesn't check for a change in file permissions.

[iluuu1994]

I'm not sure whether it should. After actually changing the file after changing the permissions shows a "Permission denied" error as expected. Any additional check for file permissions doesn't seem useful to me. Note that you don't need to restart the entire operating system, just refreshing your webserver/FPM (depends on what SAPI you're using) opcache will be cleared and the file will be loaded from disk again.

[nielsdos]

Perhaps it shouldn't yeah, especially as the work-around is pretty easy. Although I wonder what the use-case of OP was.

@Ravenman How did you discover this? What's the use-case in which you discovered this behaviour?

[Ravenman]

I'm not sure whether it should. After actually changing the file after changing the permissions shows a "Permission denied" error as expected. Any additional check for file permissions doesn't seem useful to me. Note that you don't need to restart the entire operating system, just refreshing your webserver/FPM (depends on what SAPI you're using) opcache will be cleared and the file will be loaded from disk again.

I did this test again and restarting the web server is not enough, it is necessary to restart the whole operating system to take the changes applied on the permissions of the files.

[iluuu1994]

@Ravenman How are you using PHP? FPM? If so, you need to refresh the FPM service. Restarting the webserver is necessary when using the Apache SAPI.

[Ravenman]

Perhaps it shouldn't yeah, especially as the work-around is pretty easy. Although I wonder what the use-case of OP was.

@Ravenman How did you discover this? What's the use-case in which you discovered this behaviour?

One API works changing the permissions file in the operative system but does not work as expected, so I did this raw test.

[Ravenman]

@Ravenman How are you using PHP? FPM? If so, you need to refresh the FPM service. Restarting the webserver is necessary when using the Apache SAPI.

Yes, the server API is FPM/FastCGI. I restarted the FPM service but nothing changed.

[iluuu1994]

Hmm, that's odd. What ini settings are modified? I don't really understand how this could happen.

[Ravenman]

Hmm, that's odd. What ini settings are modified? I don't really understand how this could happen.

No settings have been modified. All testing has been done with the default installation of the operating systems, the web servers and the PHP servers.

[iluuu1994]

Could you provide your ini settings (may depend on the distribution) and configuration (e.g. web-server), and steps to reproduce (i.e. command to restart fpm)?

[Ravenman]

Could you provide your ini settings (may depend on the distribution) and configuration (e.g. web-server), and steps to reproduce (i.e. command to restart fpm)?

Here are the files: config_files.zip.zip

Steps to reproduce: They are in my first post about this report.

Commands to restart FPM: systemctl restart nginx, systemctl restart php-fpm

[iluuu1994]

@Ravenman There must be more parts to the configuration.

• The nginx config doesn't include a fast-cgi section
• The PHP opcache config is not included

Could you also provide those? Thank you!

[Ravenman]

@Ravenman There must be more parts to the configuration.

* The nginx config doesn't include a fast-cgi section

* The PHP opcache config is not included

Could you also provide those? Thank you!

I'm not sure about the PHP opcache config so I included all the config files that I found. Let me know if I forgot some one, please. Thanks a lot by your help and patience.

config_files_2.zip

[bukka]

I see file cache commented out in FPM config but not sure if it is also disabled everywhere else as the main php.ini is missing. Can you check if it is still enabled (see in phpinfo)? Try also clear its directory. Nothing else should really persist in FPM restart so this is the only thing that comes to my mind but not exactly sure how file cache works - would have to check.

[bukka]

Just had a quick look and it should get used only if opcache.file_cache is set so check that value in your phpinfo.

[Ravenman]

I'm attaching one phpinfo screenshot in case it may be useful:

[iluuu1994]

So opcache isn't even enabled which makes this more odd. This means that php-fpm would have to re-read the files without having permissions...

[bukka]

I just tested it with FPM (without opcache) and Apache and getting normally a permission error (interestingly there seems to be a memleak that I found during the testing but that just confirms there does not seem to be an issue on the FPM side. I should add that I tested it locally with a debug build only so far.

Would you be able to provide exact steps how to reproduce this. Ideally starting in the fresh VM ? I could potentially also look to the configured system if you have some test instance already configured with this problem present and happy to give me SSH access there to test it (should have some availability for that in early May as I run out of my FPM time this month). First variant with a fresh VM and steps is preferred though...

[github-actions]

No feedback was provided. The issue is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so. Thank you.