blog.nowiasz.de
Private Ansichten
  • Start
  • Anleitungen
    • Automatisierte Let’s Encrypt Wildcardzertifikate mit lokalem BIND
    • Upgrade Bahncard
    • Installation von Hubzilla
    • Zwei-Faktor-Authentifizierung für KeePass (Linux/Android)
  • Galerien
    • Australien
    • Geocaching
    • Boot
    • Sonstige
  • Kontakt
Linux

Mailmerkwürdigkeit: PHP-CLI vs mod_php

by Mark Nowiasz März 1, 2017 2 Comments

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.

Print Friendly, PDF & Email
Tweet about this on Twitter
Twitter
Share on Facebook
Facebook
Pin on Pinterest
Pinterest
Email this to someone
email
  • Previous Nie wieder Samsung (Mobiltelefone)4 Jahren ago
  • Next Neue Mitbewohner4 Jahren ago

2 Replys to “Mailmerkwürdigkeit: PHP-CLI vs mod_php”

  1. Jens Kögler sagt:
    2017-10-05 um 16:06 Uhr

    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

    Antworten
    1. Mark Nowiasz sagt:
      2017-10-05 um 18:59 Uhr

      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

      Antworten

Schreibe einen Kommentar Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht.

Captcha * Time limit is exhausted. Please reload CAPTCHA.

Archive

Kategorien

  • Entertainment (5)
  • Fahrrad (4)
  • Geocaching (3)
  • Katzen (1)
  • Linux (8)
  • Misc (2)
  • Politik (2)
  • Reisen (14)
  • Sonstiges (26)
  • Sportboot (2)
  • Unterhaltung (12)

Schlagwörter

Australien (13) Bundestag (1) Deutsche Bahn (2) Drupal (4) FDP (1) Film (3) geocaching.com (1) Grüne (1) Hongkong (1) Kino (1) Literatur (3) Literature (2) Movie (2) Möbel (3) Personal (1) Persönliches (21) Politik (1) Rant (14) Review (6) Rezension (3) Service (6) Spam (2) Spotify (1) Stephen King (1) Versatel (2) Vodafone (4) WordPress (5)

Neueste Kommentare

  • Michael Mueller bei Neue Adresse des Blogs
  • Mark Nowiasz bei RIP Google+, Willkommen hubzilla (Teil 1)
  • -thh bei RIP Google+, Willkommen hubzilla (Teil 1)
  • Mark Nowiasz bei RIP Google+, Willkommen hubzilla (Teil 1)
  • -thh bei RIP Google+, Willkommen hubzilla (Teil 1)

Meta

  • Anmelden
  • Feed der Einträge
  • Kommentare-Feed
  • WordPress.org
2021 blog.nowiasz.de. Donna Theme powered by WordPress