Bugzilla – Bug 1200234
apparmor blocks access of php-fpm to scripts under $HOME/public_html
Last modified: 2022-12-12 20:56:53 UTC
After the upgrade from Leap 15.3 to Leap 15.4 a php webpage with scripts located under $HOME/public_html was no longer working. The webserver log said: 2022-06-03 17:55:06: (mod_fastcgi.c.451) FastCGI-stderr:Unable to open primary script: /home/user/public_html/project/index.php (Permission denied) /var/log/audit/audit.log: type=AVC msg=audit(1654271706.674:267): apparmor="DENIED" operation="open" profile="php-fpm" name="/home/user/public_html/project/index.php" pid=2282 comm="php-fpm" requested_mask="r" denied_mask="r" fsuid=473 ouid=1000 Adding read access to scripts in the directory restored the functionality: cat /etc/apparmor.d/local/php-fpm # Site-specific additions and overrides for 'php-fpm' @{HOME}/public_html/**/*.php r, In the release notes of Leap 15.4 I did not find a hint that public_html is deprecated and which directory should be used instead. For Leap 15.3 the access to home directories was restored after applying systemd hardening settings, see bug 1195465. Therefore I think either the apparmor profile should be updated or the release notes should give a recommendation where to move such projects.
Sorry for the late answer! Leap 15.4 comes with AppArmor 3.0.x while 15.3 had AppArmor 2.13.x. This version update also added the php-fpm profile. There are no plans to deprecate using ~/public_html, but it seems it's used rarely enough that you are the first to hit this issue.
(In reply to Christian Boltz from comment #1) > Sorry for the late answer! > > Leap 15.4 comes with AppArmor 3.0.x while 15.3 had AppArmor 2.13.x. This > version update also added the php-fpm profile. > > There are no plans to deprecate using ~/public_html, but it seems it's used > rarely enough that you are the first to hit this issue. No problem, to apply the local fix is easy enough. It is great that Leap 15.4 got this AppArmor version update with additional profiles!
I think this might affect the access to not only $HOME/public_html but also /srv/www/htdocs. But I do not know for sure as I do not have the knowledge to tell. I just upgraded my home server from lp153 to lp154. After that, self-hosted Nextcloud on that server cannot be accessed. It throws out 403 error when access php files but response normally when requesting normal file like .ico file. With information in this bug report, I found that there are messages like following, `type=AVC msg=audit(1668739699.011:2625): apparmor="DENIED" operation="open" profile="php-fpm" name="/srv/www/htdocs/nextcloud/index.php" pid=559 comm="php-fpm" requested_mask="r" denied_mask="r" fsuid=498 ouid=498` Hopefully this information is helpful for implement fix to such issue.
I just hit this bug as well. As a workaround I added to /etc/apparmor.d/local/php-fpm: allow /srv/www/htdocs/** rw, Maybe add this and the public_html one as a default?
(In reply to Fabian Niepelt from comment #4) > I just hit this bug as well. > > As a workaround I added to /etc/apparmor.d/local/php-fpm: > > allow /srv/www/htdocs/** rw, > > Maybe add this and the public_html one as a default? Sorry but I would consider granting write permissions too generous. Are they really needed?
Admittedly, the write permission might not be required for everyone. In my case it is required because I have a pastebin and a file-sharing service which allows users (well, primarily me) to upload data to the server that gets saved in the filesystem so the php-fpm permission needs write permission to do exactly that. PHP applications in general might also want to write logs. Someone who isn't aware of Apparmor will probably spend a lot of time trying to figure out why their application is not working correctly with it not even writing internal logs. This is probably a question of security vs. expectations I think. It is expected for a PHP application to work if it's put into the appropriate document root (/srv/www/htdocs in this case) and configuring the webserver accordingly. Currently, this does not work at all due to no permissions being given to htdocs at all by Apparmor. With just a read permission on htdocs, some applications work correctly, others will work up until PHP needs to store data (and doesn't use a database for it). With the read-write permission, I guess most applications would work decently, but for example in my use case I also needed to add rw permission on /tmp and r permission on /etc/ImageMagick*/* to the profile. Personally, I would allow rw on /srv/www/htdocs and /tmp. However, there should also be a notice to the user somehow that php-fpm is restricted by Apparmor because PHP applications have vastly different requirements.