Das wwwrun-Problem

Es lassen sich keine Erweiterungen installieren oder updaten? Das könnte ein sogenanntes wwwrun-Problem sein. Was es damit auf sich hat, kann hier nachgelesen werden.

Um das wwwrun-Problem zu verstehen, muss man sich vergegenwärtigen, wie ein Webservers arbeitet. Dieser besteht aus einer Mischung von allgemeiner Software – die für alle Benutzer zur Verfügung steht – und den Applikationen die sich ein Kunde in auf seinen Webspace lädt. Das kann ein Blog sein, kann ein CMS wie Joomla! sein, kann auch eine Sammlung von rein statischen Webseiten sein.

In einem Shared Hosting Paket teilen sich mehrere Kunden denselben Server. Jeder Kunde besitzt seine eigenen Verzeichnisse und jeder Kunde verfügt über einen eigenen Benutzer-Account, auf den er per FTP zugreifen kann. Damit sich diese nicht in die Quere kommen können, muss der Hoster dafür sorgen, dass jeder einzelne Account strikt von allen andern getrennt ist. Ein Kunde darf also nicht auf die Daten eines andern Kunden zugreifen können.

Der Webserver (meinst ist das ein Apache) braucht natürlich seinerseits vollen Zugriff auf sämtliche Daten auf seinem Server, um die Seiten an die einzelnen Besucher ausliefern zu können. Es gibt pro Server nur einen Apatchen, und der muss allen Kunden zur Verfügung stehen.

Jeder Account steht also einem Besitzer zur Verfügung, er befüllt seine Webpräsenz mit Daten. Und der Webserver muss an diese Daten herankommen. Solange es dabei nur lesenden Zugriff braucht, ist die Welt in Ordnung. Sobald aber der Webserver auch schreiben können muss, haben wir ein Problem. Das wwwrun-Problem. Die Sache ist nämlich die:
Die meisten Webserver laufen unter einem UNIX-ähnlichen Betriebssystem. UNIX kennt (wie übrigens andere Betriebssysteme auch) eine strikte Rechteverwaltung. UNIX kennt ein Recht zum Lesen (r), ein Recht zum Schreiben (w) und ein Recht zum Ausführen (x) (von Programmen etc.) [siehe auch UNIX/Linux/ Access Modes File Permissions]. Zudem kennt UNIX drei Sorten von Benutzern: Der Eigentümer (owner) einer Datei (bzw. eines Verzeichnisses), die Gruppe (group) und alle andern (world). Rechte werden diesen Benutzern zugeordnet, und das Ganze wird dann in einer 3x3 Matrix abgebildet, vovon die Rechte oft als Zahlenkolonne mit 3 Ziffern dargestellt werden.
In diesem Sinn bedeutet 777, das jeder alles darf: Besitzer, Gruppen und alle Andern haben volle Rechte. Bei Joomla ist die Vorgabe für Verzeichnisse: 755 (Besitzer: rwx, alle Anderen: rx), für Dateien 644 (Eigentümer:rw, alle Anderen:r). Das sollte eigentlich genügen, nur: Was ist mit dem Apatchen? Dieser muss ja eigentlich zusammen mit seinem im Schlepptau befindlichen PHP Interpreter alles können: Lesen, Schreiben und Ausführen. Will sagen, er braucht die Rechte eines Besitzers. Oder zumindest der PHP Interprater braucht selbige. Wir erinnern und: Der Kunde hat Dateien hochgeladen per FTP, er ist also der Besitzer dieser Dateien. Der Apache ist zwar zusammen mit PHP durchaus in der Lage, schreibend in den Kundenaccount zu werkeln, nur gehören seine Dateien dann dem Benutzer wwwrun (der aus Sicht des Betriebssystems ist der Apachen auch ein Benutzer, oft nennt sich dieser wwwrun), und nicht dem Kunden, der Kunde kann die Daten des Apachen nicht ändern und umgekehrt geht es auch nicht.

Der Ausweg ist einfach: Der PHP Interpreter darf nicht als Apache-Modul eingebunden werden, sondern per cgi-fcgi (CGI/FastCGI). Damit lässt sich das Rechteproblem lösen. Die Last auf dem Server wird dadurch leicht höher (weshalb einige Billighoster dies nicht anbieten), dafür bekommt man aber ein sauberes Rechtesystem.

Merke: Datei- und Verzeichnisrechte 777 sind ein Ding des Teufels, sie öffnen sicherheitsmässig Scheunentore und machen eine Webseite angreifbar.

Kleines Mitbringsel: Linux is like a tent: no windows, no gates and an apache inside