PHP mittels SuExec als CGI unter Gentoo

---

Als erstes muss SuExec nat?rlich laufen. Das war bei uns schon vorher der Fall, trotzdem nochmal kurz zusammenfassend: SuExec braucht zur Kompilierzeit bereits die Angabe des Document-Root, also das Verzeichnis in dem alle Scripts drin sind. Gentoo stellt dieses auf /var/www ein, da wir /home haben wollen, mussten wir das ebuild patchen. jedenfalls steht da jetzt --with-suexec-docroot=/home.

Dann wird in jedem VHost eingetragen, als welcher user die CGIs in diesem Verzeichnis gestartet werden sollen:

SuExecUserGroup bernd users

Um nun die PHP-Files (und das war mein Knackpunkt) ohne Modifikation und ohne excutable-Flag ausf?hren zu k?nnen, brauchen wir diese Zeilen in der VHost-Konfiguration:

RemoveHandler .php
ScriptAlias /cgi-wrapper /home/.internal/cgi/bernd
AddType application/cgi-php php
Action application/cgi-php /cgi-wrapper/php

Dabei l?scht die erste Zeile nur die Zuordnung zum mod_php, d.h. mod_php vergisst dann bei diesem VHost, dass es f?r PHP-Files zust?ndig ist.
Die zweite Zeile setzt ein ScriptAlias, sodass ich pro user nur ein Verzeichnis mit dem CGI-Wrapper brauche, nicht pro VHost. Es muss bei mir innerhalb /home liegen, weil eben unser SuExec nur in /home arbeiten mag. Im home-Verzeichnis des users wollte ich es nicht haben, da mir die Gefahr zu gro? ist, dass der user das l?scht. :)
Zeile 3 setzt einen neuen Typ f?r Dateien, die auf .php enden. So liessen sich auch ganz einfach unterschiedliche PHP-Versionen mit verschiedenen Endungen realisieren.
Die letzte Zeile sagt dem Apache, dass er Dateien des eben definierten Typs bitte durch das hinten angegebene CGI-Script schicken soll.

Eine Idee war, dass man den ScriptAlias auch zentral setzen k?nnte und dann nur eine Instanz des PHP-CGI-Wrapper br?uchte, aber das scheitert an der Tatsache, dass SuExec genau pr?ft, dass sowohl das Script als auch das Verzeichnis in dem das Script liegt, dem User geh?ren, der per SuExecUserGroup gesetzt wurde.
Also brauchen wir ein Verzeichnis pro user. Wie wir gleich sehen werden, bringt und das sogar noch mehr M?glichkeiten.

Mir gef?llt die Idee nicht, ein PHP-Binary pro User zu haben, das ist im Falle eines Updates ziemlich undurchsichtig. Daher habe ich folgende L?sung implementiert: In das Wrapper-Verzeichnis kommt ein CGI-Script mit dem Name php und folgendem Inhalt:

#!/bin/sh
exec /usr/bin/php-cgi "${PATH_TRANSLATED}"

Das bedeutet, das CGI-Script ist ein Shellscript, das den PHP-Interpreter aufruft. Ob das Performance-Probleme bringt, konnte ich noch nicht testen, aber ich w?sste nicht wieso.

Hinweis: Ich hab jetzt mehrfach feedback bekommen, in dem Leute vorgeschlagen haben, ob nicht ein symlink auf das php-executable reichen w?rde. Antwort: Nein, das reicht nicht. Aus zwei Gr?nden:
1. l?st apache Symlinks intern auf, er wweiss also letztlich, dass er /usr/bin/php-cgi starten soll. Das tut er aber nicht, weil /usr/src laut apache-config kein freigegebenes Verzeichnis ist (das ich auch nicht freigeben will). SuExec w?rde das auch nicht m?gen, wenn das binary nicht in /home liegt.
2. SuExec verlangt, dass sowohl das binary als auch das Verzeichnis in dem das binary liegt, dem user geh?rt, unter dem es ausgef?hrt werden soll. Aber dazu lese weiter. ;-)

Wichtig ist jetzt, dass eben das Verzeichnis mit dem Wrapper dem user geh?rt, dessen Scripts damit bearbeitet werden und dass sowohl dieser user als auch der user unter dem apache l?uft, die Datei lesen und ausf?hren d?rfen. Die Script-L?sung hat auch den Vorteil, dass man jedem user individuelle PHP-Kommandozeilenparameter einstellen kann.

So, ich weiss jetzt nicht ob das eine brauchbare Anleitung geworden ist, jedenfalls hoffe ich, dass es jemandem hilft, so wie Tobias mir geholfen hat.