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)?