Montag, 20. August 2012
Apache HTTPd + FastCGI + SuExec + PHP
Vor ein paar Jahren hatte ich schon einmal versucht PHP-Prozesse auf dem Webserver in ein chroot()-Jail zu stecken. Auch wenn ich seinerzeit ein paar Erfolge verzeichnet hatte, haben es meine damaligen Bemühungen nie in den Produktions-Betrieb geschafft - der Gedanke daran jedoch blieb.
Aus heutiger Sicht weiß ich gar nicht mehr, was ich seinerzeit alles angestellt habe, es war auf jeden Fall kompliziert. Wenn man den Punkt ein Jail zu bauen, dass alle notwendigen Anwendungen und Bibliotheken enthält, außen vor lässt hat man - wie im Titel bereits erwähnt - immer noch 4 Komponenten, die miteinander arbeiten müssen. Am wichtigsten hier ist, dass das was am Anfang in der Kette eingegeben wird am anderen Ende einen gültigen Wert besitzt. In einem "normalen" Setup ist das stets gegeben, in einer chroot()-Umgebung ist eine der wichtigsten Eigenschaften - der Pfad zur Skript-Datei, die ausgeführt werden soll - falsch. Was also tun?
Fangen wir mal am Anfang an: Der Webserver (httpd) nimmt eine HTTP-Anfrage entgegen, mod_fcgid fühlt sich für diese verantwortlich und startet (bei Bedarf) mittels SuExec einen PHP-FastCGI-Server.
Der einzige Teilnehmer in dieser Kette, der aktiv "weiß" dass ein chroot()-Jail existiert, ist SuExec, denn an diesem Punkt wird es auch initiiert. Bei einer einfachen CGI-Anwendung könnte SuExec auch die Umgebungs-Variablen umschreiben, bei FastCGI hingegen wird SuExec einmal ausgeführt und kann für "beliebig viele" Anfragen verwendet werden. Maßgeblich ist dabei nur die User-/Group-ID unter der der Skript ausgeführt wird, die Pfade hingegen können vollkommen verschieden sein (z.B. wenn mehrere Domains vom selben Benutzer verarbeitet werden).
Als Konsequenz hieraus müssen nun im FastCGI-Server (PHP) ein paar Anpassungen vorgenommen werden, denn PHP wird immer die vollen Pfade von außerhalb des chroot()s mitbekommen und wird damit nichts anzufangen wissen.
Als einfachste und naivste Lösung könnte man im neuen Root (sei es /home/chroot) einen gleich lautenden Link auf sich selbst erzeugen (/home/chroot/home/chroot -> ../../). Das ist aber sehr dreckig und ich würde es als Methode für ein Produktiv-System nicht zulassen.
Eine bessere Lösung bietet PHP selbst mit seiner doc_root-Direktive in der php.ini: Wird vom Webserver die Umgebungsvariable DOCUMENT_ROOT nicht übertragen, wird dieser Wert beim Suchen von Skripten zur Rate gezogen. Bis PHP 5.3 eigentlich auch nicht nutzbar, da der Wert nur global zu definieren war. Mit Einführung der konditionalen Sektionen in der php.ini ist dieses Feature jedoch recht brauchbar geworden. Allerdings muss man hier jede Domain bzw. jeden Pfad in einer weiteren Datei (der php.ini) konfigurieren - ein weiterer Punkt, wo sich Fehler einschleichen können - besonders wenn man plant, die php.ini komplett in fremde Hände zu geben.
Die für mich sinnvollste Variante war aber eher etwas mehr "Bewusstsein" für die chroot()-Umgebung in PHP zu wecken. Hierzu muss man PHP von außen einen Tipp geben, wo es sich befindet - am einfachsten über eine neue Umgebungsvariable, die in SuExec gesetzt und von PHP beim Finden der Skript-Datei genutzt wird. Der FastCGI-Server lässt diese Variablen auch zwischen den Anfragen intakt, sodass sie bis zum Ableben des Servers erhalten bleiben. Wir schreiben in diese Variable einfach vor dem Aufruf von chroot(), wohin diese Anfrage geht und gleichen sie in PHP dann mit den Variablen SCRIPT_FILENAME und DOCUMENT_ROOT ab. Bei Bedarf werden letztere Beschnitten und gut ists - für die ausgeführten PHP-Skripte sieht es nach einer ganz normalen Umgebung aus.
Kombiniert man das mit einem FTP-Server und einem SSH-Server (mit SCP, SFTP und RSync) die beide nach dem selben Schema chroot()s aufbauen wird es eine runde Sache. Ich freue mich! 
Apropo, warum eigentlich Chrooted-Umgebungen, was bringt das in deinen Augen?
Bei uns wird der chroot() natürlich primär zur Abschirmung zwischen den Kunden dienen. Bisher bedienen wir uns hier dem open_basedir von PHP und einer shared Library die wir selbst entwickelt haben und als Wrapper vor anderen Prozessen laden.
Der chroot() entspannt das alles etwas. Im ersten (produktiven) Deployment räumen wir den Kunden sehr viel mehr Freiheiten ein, darunter z.B. ein voller Zugriff auf die php.ini, ein SSH-Zugang und die Möglichkeit eigene Programme auf dem Server auszuführen (also solche, die kein PHP-Skript sind) - selbstredend, dass dann auch so Funktionen wie exec() oder system() freigegeben sind.
Als Nebeneffekt sind alle Pfade wie der Kunde sie sieht identisch - bisher lief nur der FTP-Server im chroot(). Das führte dazu, dass Pfade wie "/hosts/domain/datei.php" (FTP) in Wirklichkeit "/home/kunde/hosts/domain/datei.php" (HTTPD, PHP) waren, was mitunter zu Irritationen führte.
Der Webserver kann jede Datei lesen, also mache ich aus meinem chroot heraus einen symbolischen Link zum Nachbarkunden (man kann sicher erraten, welches Verzeichnis es ist) und kann dort seine Konfiguration auslesen, im dem ich sie mir im Webserver auslesen lasse.
Symbolische Links kann man verbieten, aber dann gehen diverse Sachen nur noch umständlich, bzw. diverse PHP Anwendungen müssen manuell angepasst werden.
Man kann Symbolische Links zulassen, wenn Quelle und Ziel dem gleichen Benutzer gehören, aber dann kann man keine globalen Pakete bereit stellen, z.B. Typo3 für alle Kunden.
Weiterhin kann der APC Cache von PHP nicht mit mod_f*cgi umgehen. Damit verschenkt man Serverleistung.
Und als Bonus wäre jetzt noch WebDAV interessant, so dass jeder Kunde seinen Webspace direkt einmounten kann. Man könnte zwar einen PHP WebDAV Server nehmen, aber dann sind Apple Kunden ausgesperrt, da die chunked Requests nicht mit mod_f*cgi gehen.
Eine Lösung würde mich auch interessieren
Aber bitte ohne Patches, das soll auch noch in 10 Jahren laufen.
Das APC mit mod_fcgid den Cache nicht zwischen den Prozessen teilen kann ist ein alter Hut und das "Problem" existiert bei uns schon immer. Der Overhead ist aber minimal, da anstelle eines globalen Caches pro FastCGI-Server ein Cache existiert, der Worst-Case ist also, dass ein Skript 3-4x anstatt einmalig gecached wird, alle weiteren Anfragen profitieren von einem der Caches - die Frage ist dann nur, wie lange man die FastCGI-Server leben lässt (und natürlich ist der Verbrauch von Arbeitsspeicher höher - das ist mir aber lieber als mod_php einzusetzen)
Mir ist btw. kein Kunde bei uns bekannt, der Symlinks einsetzt. Da FTP nach wie vor das Upload-Mittel der Wahl ist, ist das Anlegen auch hochkompliziert. Auch wir symlinken nicht, sondern setzen eher einen Alias im Webserver direkt. In einer chroot()-Umgebung entfällt der Alias natürlich wenn es um PHP-Skripte geht, aber genau so würde hier ein symlink nicht weiterhelfen, insofern verliere ich hier rein gar nichts.
Genau so, wie wir im chroot() eine Laufzeit-Umgebung bereitstellen müssen, können wir dort auch zentral gemanagede PHP-Applikationen verwalten und an die Kunden verteilen. Das tut nur auf Storage-Ebene weh, ist mir aber fast lieber, wenn ich weiß, dass kein Code gemeinsam zwischen mehreren Kunden einsetzt.
Was die Symlinks aus dem chroot() hinaus angeht: Das bekommt der Webserver dank Patch mit. Geht nicht!
(Zumal man den Pfad vielleicht erraten kann, aber trivial ist das nicht mehr)
Suche
Read this blog!
Kategorien
Blog abonnieren
Buttons
