Heute habe ich ein Problem debugged, was mich immer noch vor ein Rätsel stellt: Die unterschiedliche Behandlung der PHP-Funktion mail() – einerseits via Commandline, anderseits via Apache/mod_php bei mir. Die Eckdaten:
- Apache 2.4.25 mit mod_php
- PHP 7.0.16 (gleiche Problem aber auch mit 7.1.2, womit einer meiner WordPressplugins nicht funktioniert)
- Postfix 3.1.4
Das Problem
Ich bin darauf gestoßen, dass WordPress keine Mails mehr verschickt. In den Errorlogs fande ich dann so etwas:
postdrop: warning: mail_queue_enter: create file maildrop/830134.28039: Permission denied
Mit strace an den Prozess gehängt sah ich in der Tat, dass postdrop nicht schreiben durfte. Permissions von postdrop waren aber völlig OK (-rwxr-sr-x 1 root postdrop 14832 Jan 29 12:24 /usr/sbin/postdrop). Zuerst ging ich von einem Bug in WordPress aus, denn als user apache konnte ich problemlos mail verschicken. Schließlich habe ich ein kleines Test-PHP-Programm geschrieben, dass mittels mail() eine Testmail versenden sollte. Von der Konsole aus – als User apache – klappt es mit php -f problemlos. Sobald jedoch der Apache das PHP-Skript ausführen wollte, hing der Prozess – mit der o.g. Fehlermeldung, die sich immer weiter wiederholte.
Um auszuschließen dass es an unterschiedliche Konfigurationen lag, habe ich die Konfiguration des CLI PHP in die des Apache PHP kopiert, kein Unterschied. Interessant noch: der postdrop-Prozess unter dem hängenden Apache lief als User apache/apache, obwohl das setgid-Bit gesetzt war.
Ach ja, bevor ich es vergesse: evtl. .htaccess oder vhost-Direktiven habe ich natürlich überprüft. Nichts besonderes.
Schließlich halt nur noch eins: den User apache in die Gruppe postdrop packen, danach funktionierte es wieder.
Jetzt stehe ich vor einem echten Rätsel: Was genau unterscheidet einen Apache-Prozess mit mod_php unter der UID/GID apache von einem Shell-Prozess (cli php) mit den gleichen UID/GIDs? Wieso wird in dem einen Fall das setgid-Flag von postdrop beachtet (cli) im anderen Fall (mod_php) nicht?
OK, der Workaround funktioniert, aber es gefällt mir dennoch nicht – weil es eigentlich sauber hätte funktionieren sollen und eigentlich auch bis vor einer Weile noch funktioniert hat. Sehr rätselhaft, bei Google ist auch nichts zu finden.
Bei Einsatz von systemd und gehärtetem systemd-unit des Apaches darf auf keinen Fall die Option NoNewPrivileges=false gesetzt sein. Einfach mit systemctl edit apache2.service eine Sektion [Service] anlegen und NoNewPrivileges=false mit einer neuen Zeile überschreiben. Wenn beides der Fall ist, kommt es genau zu diesem Fehler
Ah, danke für den Tip. Allerdings scheint das Gentoo-Service-File NoNewPrivileges=true zu haben, aber dennoch ist das eine wirklich heiße Spur:
PrivateTmp=true
#Hardening
PrivateTmp=true
CapabilityBoundingSet=CAP_CHOWN CAP_SETGID CAP_SETUID CAP_DAC_OVERRIDE CAP_KILL CAP_NET_BIND_SERVICE CAP_IPC_LOCK
SecureBits=noroot-locked
ProtectSystem=full
NoNewPrivileges=true
PrivateDevices=true
MemoryDenyWriteExecute=true