Problem with FastCGI + SuEXEC: all sites running under www-data after update

[thompol]

Frequently asked questions

• I have read Frequenty Asked Questions

I have seen several reports on HowToForge where there was a problem with php-cgi in combination with SuEXEC after updating from the SURY repo. These issues started after the 16th of february.
The following threads explain the issue in depth and shows the debugging steps done so far:
https://www.howtoforge.com/community/threads/files-with-www-data-permission.86388/
https://www.howtoforge.com/community/threads/solved-cant-login-ispconfig-3-2-interface.86395/
https://www.howtoforge.com/community/threads/suexec-works-fine-for-php-fpm-but-fast-cgi-suddenly-runs-under-www-data-only-suexec-log-empty.86409/

I have reproduced it myself on a Ubuntu 20.04 test system. Instead of running as the correct user, it is running as www-data which does not have access to the web folder and will therefore generate a error 404. I can't find the underlying problem.

If you understand the purpose of this issue tracker and describe your problem accurately (where the template below will help), I might be able to help you.

To Reproduce
Steps to reproduce the behavior:

1. Install your system (I installed the test system using https://git.ispconfig.org/ispconfig/ispconfig-autoinstaller)
2. The sites (I used the panel for testing) work.
3. Enable http2 by running these commands:
4. a2enmod http2
a2enconf php7.4-fpm
systemctl reload apache2
a2dismod php7.4
systemctl restart apache2
a2dismod mpm_prefork
a2enmod mpm_event
systemctl restart apache2
5. Open a FastCGI site (in my testing the panel). You will see the 404 error.
   (in the threads there are some in-depth explanations aswell)

Expected behavior
The sites to keep working, like they used to. To be clear, there were no other changes made to these setups between the working and non-working system.

Distribution (please complete the following information):

• OS: Ubuntu 20.04
• Architecture: x86_64
• Repository: Ubuntu PPA

[oerdnj]

See https://www.patreon.com/posts/february-update-47617742 the point number 1) in packaging changes, more specifically the change was:

diff --git a/debian/php-fpm.conf b/debian/php-fpm.conf
index 3fc2f80c0..1d78fbb48 100644
--- a/debian/php-fpm.conf
+++ b/debian/php-fpm.conf
@@ -7,7 +7,9 @@
     </IfModule>

     <FilesMatch ".+\.ph(ar|p|tml)$">
-        SetHandler "proxy:unix:/run/php/php@PHP_VERSION@-fpm.sock|fcgi://localhost"
+        <If "-f %{REQUEST_FILENAME}">
+            SetHandler "proxy:unix:/run/php/php@PHP_VERSION@-fpm.sock|fcgi://localhost"
+        </If>
     </FilesMatch>
     <FilesMatch ".+\.phps$">
         # Deny access to raw php sources by default

Could you try reverting the change and see if that helps? I will revert the change in such case, it's recommended by Apache2, but perhaps it's not universal.

[thompol]

Thanks for your incredible fast response.

Yes, reverting this change fixes the issue.

[thompol]

I have opened a FAQ for it on our forum so users can follow the steps there as temporary fix: https://www.howtoforge.com/community/threads/faq-problem-with-fastcgi-suexec-all-sites-running-under-www-data.86419/

[oerdnj]

Packages with the reverted change are building now.

[thompol]

Thanks for your quick action on behalf of the whole HTF community and others!

[thompol]

It seems like it has not been changed in the PHP 8.0 package - could you verify this?

[oerdnj]

php8.0 (8.0.2-5) unstable; urgency=medium

  * Revert "Don't pass URLs for missing files to PHP-FPM"

 -- Ondřej Surý <ondrej@debian.org>  Fri, 19 Feb 2021 16:33:16 +0100

[thompol]

Weird, it's still in my config after updating.

[oerdnj]

Here's the correct paste:

ondrej@calcifer:/tmp$ curl -sSLO https://launchpad.net/~ondrej/+archive/ubuntu/php/+files/php8.0-fpm_8.0.2-5+ubuntu20.04.1+deb.sury.org+1_amd64.deb
ondrej@calcifer:/tmp$ dpkg-deb -x php8.0-fpm_8.0.2-5+ubuntu20.04.1+deb.sury.org+1_amd64.deb php8.0-fpm
ondrej@calcifer:/tmp$ cat php8.0-fpm/etc/apache2/conf-available/php8.0-fpm.conf
# Redirect to local php-fpm if mod_php is not available
<IfModule !mod_php8.c>
<IfModule proxy_fcgi_module>
    # Enable http authorization headers
    <IfModule setenvif_module>
    SetEnvIfNoCase ^Authorization$ "(.+)" HTTP_AUTHORIZATION=$1
    </IfModule>

    <FilesMatch ".+\.ph(ar|p|tml)$">
        SetHandler "proxy:unix:/run/php/php8.0-fpm.sock|fcgi://localhost"
    </FilesMatch>
    <FilesMatch ".+\.phps$">
        # Deny access to raw php sources by default
        # To re-enable it's recommended to enable access to the files
        # only in specific virtual host or directory
        Require all denied
    </FilesMatch>
    # Deny access to files without filename (e.g. '.php')
    <FilesMatch "^\.ph(ar|p|ps|tml)$">
        Require all denied
    </FilesMatch>
</IfModule>
</IfModule>

[thompol]

Alright, probably a fluke when updating. Thanks again!

[thompol]

One more question :)

When do you expect the update to be available in the Debian repo?

[MichaIng]

It's available now, I was just upgrading php8.0(-fpm) from the repo with the patch + revert (hence no <If "-f %{REQUEST_FILENAME}">).

I was always wondering why even non-existing files are passed to FPM and added the check manually to my configs manually. But it makes sense as webserver and PHP handler do not necessarily run with the same user/permissions.

However, one might argue that the default setup on Debian is with Apache2 and PHP-FPM running both as www-data, and hence the default config might better be optimised for this case. If an admin or Debian-based distro runs webserver and PHP as different users, the default Apache2 php-fpm config can and needs to be adjusted then. But I'm not sure how big the overhead for a server finally is, I mainly added the file check to mute the disturbing noscript error messages. And if the benefit of the check outweighs the compatibility-regression, then it might be still better to do it as part of a PHP major version transition, e.g. with first php8.1 packages, as it is a breaking change.

[oerdnj]

And if the benefit of the check outweighs the compatibility-regression, then it might be still better to do it as part of a PHP major version transition, e.g. with first php8.1 packages, as it is a breaking change.

I am not sure about the benefit here - one could argue that a default setup should work for everybody and if you want performance you need to fine tune the setup. Perhaps the improved configuration could be added commented-out to the config?

[MichaIng]

one could argue that a default setup should work for everybody and if you want performance you need to fine tune the setup

Fair point.

Perhaps the improved configuration could be added commented-out to the config?

I like that idea 👍.

[thompol]

Yes, perhaps it could be added with comments. It might be interesting for some users.