Overview
Request 754580 revoked
- relax systemd restrictions for FPM as they were too strict in some applications
- change leftover Requires php7-<extension> to php-<extension>
- remove external libraries from -devel subpackage
- added patches
+ php-fpm-service-fails-to-start.patch (forwarded request 754321 from adkorte)
- Created by pgajdos
- In state revoked
- Supersedes 751575
- Open review for openSUSE:Factory:Staging:H
https://bugs.php.net/bug.php?id=78892
Note that the bug reported in the above mentioned bug report is not in the default configuration as shipped, but only if the listening socket is changed from AF_INET to AF_UNIX. So you'd have to have changed this, before hitting this.
With all additional systemd restrictions now in place, it shouldn't come as a surprise that this might also require changes to the CapabilityBoundingSet (although the documentation for this is a bit sparse in this aspect).
https://bugs.php.net/patch-display.php?bug_id=78889&patch=php-fpm.service.in.patch&revision=latest
CapabilityBoundingSet=CAP_CHOWN CAP_SETGID CAP_SETUID
No matter the default configuration or not. I do not know a single server that would work on the default configuration. Using unix socket with changing rights and mode is a standard documented function for it.
That may be, but what this patch does, is only changing the CapabilityBoundingSet. This is not necessary if the system is configured to listen on an AF_INET socket (which happens to be the default). Actually, while preparing php7-7.4.0 I ran FPM with the stock configurations.
If a packager decides to ship packages with the default listening socket changed to AF_UNIX, it is an incomplete change in the configuration if this fails to work and only the packager is to blame. It most definitely is not a PHP bug.
It worked for me. FPM is part of PHP. systemd-unit file is shipped in the PHP tarball. They decided to add a CapabilityBoundingSet to it, but they didn’t add it completely, they forgot to add CAP_CHOWN. Why do you think this is not a PHP bug?
That is, in your opinion, the administrator of the web server, in addition to the configuration files, must also configure the systemd-unit file itself, if it changes something in the configuration file?
Please revisit https://bugs.php.net/bug.php?id=78889 of which your bug report is marked as a duplicate. This is a packaging error in Arch Linux, not a PHP bug. When listening on an AF_INET socket (the default in the configuration), the CapabilityBoundingSet is correct. CAP_CHOWN is not needed, so it should not be set..
If you (as an administrator) decide you want to change the default AF_INET socket to an AF_UNIX, it is your responsibility (and yours only) to make any changes necessary in the configuration. And with PHP 7.4.0 this means that you'll also have to customize systemd by running 'systemctl edit php-fpm.service' and add an override to the CapabilityBoundingSet.
I can come up with dozens of changes to the www.conf file that will require changes elsewhere, this does not constitute a bug.
Well, we can in our downstream, given that we already have a patch for the systemd-unit file, add CAP_CHOWN so that those who use unix socket do not have to edit this file? After all, when updating a package, it is overwritten, if I'm not mistaken.
And where would we stop? There are probably other capabilities that need to be set depending on a configuration that people might use. It doesn't make sense to weaken security if not necessary (in the www.conf file as shipped it isn't).
All you need to do (once) is to run 'systemctl edit php-fpm.service' and add the following two lines:
Service CapabilityBoundingSet=CAP_SETGID CAP_SETUID CAP_CHOWN
Save the file and from now on the CapabilityBoundingSet will be overridden by this local change. See 'man 1 systemctl'.
Having said that, this could have been described more clearly in the UPGRADING documentation provided by PHP. Personally I think the hardening is a good idea, but it could have been documented a bit cleared. The note in the NEWS and the Feature Request https://bugs.php.net/bug.php?id=72510 it refers to are not enough.
I had to replace '[Service]' with 'Service' in your comment to avoid the markdown renderer crashing - https://github.com/openSUSE/open-build-service/issues/8822
Oops! Anyway, the edit of php-fpm.service should have
[Service]
on line 1 and
CapabilityBoundingSet=CAP_SETGID CAP_SETUID CAP_CHOWN
on line 2.
https://bugs.php.net/bug.php?id=78916 Mail don't send via mail(). It's not a bug too?
Maybe it is. You may want to check on the activities in https://bugs.php.net/bug.php?id=78889 again, there has been quite some activity regarding the systemd restrictions. CapabilityBoundingSet and MemoryDenyWriteExecute seem to have been removed entirely and there is some discussion going on what else needs to be relaxed. For the moment, you could 'systemctl edit php-fpm.service' and set
[Service]
```MemoryDenyWriteExecute=``` ```RestrictAddressFamilies=``` to disable these restrictions. I have submitted a request to remove the first two already, as this seems to be the new default for upstream too.
Request History
pgajdos created request
- relax systemd restrictions for FPM as they were too strict in some applications
- change leftover Requires php7-<extension> to php-<extension>
- remove external libraries from -devel subpackage
- added patches
+ php-fpm-service-fails-to-start.patch (forwarded request 754321 from adkorte)
factory-auto added opensuse-review-team as a reviewer
Please review sources
factory-auto accepted review
Check script succeeded
licensedigger accepted review
ok
staging-bot set openSUSE:Factory:Staging:H as a staging project
Being evaluated by staging project "openSUSE:Factory:Staging:H"
staging-bot accepted review
Picked "openSUSE:Factory:Staging:H"
dimstar_suse added factory-staging as a reviewer
Being evaluated by group "factory-staging"
dimstar_suse accepted review
Unstaged from project "openSUSE:Factory:Staging:H"
dimstar_suse set openSUSE:Factory:Staging:H as a staging project
Being evaluated by staging project "openSUSE:Factory:Staging:H"
dimstar_suse accepted review
Picked "openSUSE:Factory:Staging:H"
dimstar accepted review
ok
dimstar_suse declined request
> remove external libraries from -devel subpackage
This results in failures in for example graphviz-addons
php-config --libs lists:
-lcrypt -largon2 -lresolv -lcrypt -lrt -lm -ldl -ltinfo -lxml2 -lpcre2-8 -lxml2 -lcrypt -largon2 -lxml2 -lz -lcrypt
As a consequence, php7-devel is responsible to ensure all the libs it claims I have to link in plus to be present.
pgajdos revoked request
apologize, my fault