Auf unserer Multiblogging-Plattform setzen wir aus Sicherheitsgründen suPHP statt mod_php ein. Einer der großen Vorteile ist, dass Skripte so unter dem Benutzer des jeweiligen vHosts ausgeführt werden und so weder schreibbar noch ausführbar für andere Benutzer sein müssen. Da die Dateien dem vHost-Besitzer „gehören“ genügt für normale Dateien, wie z.B. Bilder, eine Linux-Dateisystem-Berechtigung von umask 644 bzw. -rwxr–r– oder auf Deutsch:  Besitzer (vHost owner) darf lesen und schreiben, der Rest – insbesondere der Apache-User www-data darf nur lesen.

Das Problem …

In der Debian / Ubuntu Default-Konfiguration für von Skripten erstellte Dateien, also z.B. für von WordPress / Buddypress erzeugte Profilbilder oder vom Plugin NextGEN Gallery erstellte Thumbnails, setzt suPHP die Berechtigung 600 bzw. -rw——-, wodurch die Dateien nicht durch den Apache-User gelesen werden können. Das führt i.d.R. zu klassischen 404-Fehlermeldungen beim Zugriff auf die URLs oder dazu, dass Bilder einfach nicht dargestellt werden, sondern lediglich deren Alternativtext (sofern überhaupt verfügbar).

Die Lösung …

… ist prinzipiell relativ einfach. Allerdings ist zur Änderung Zugriff auf die Webserverkonfiguration erforderlich, was jedoch inzwischen aufgrund der immer häufiger genutzten eigenen vServer mit Root-Zugriff vielfach gegeben ist. In diesem Fall muss lediglich der umask-Eintrag der Datei /etc/suphp/suphp.conf von 0077 (entspricht 600 in Oktalnotation) auf 0022 (entspricht 644 in Oktalnotation) geändert werden:

;Umask to set, specify in octal notation
;umask=0077

Sicherheitshalber ggf. noch den Apache-Prozess neu starten, so dass die Änderungen auch auf jeden Fall übernommen werden und ab sofort sollten von PHP-Prozessen erzeugte Dateien mit den korrekten und v.a. von Apache lesbaren Berechtigungen 644 erzeugt werden:

/etc/init.d/apache2 restart