Zugschlusbeobachtungen (Entries tagged as php)

Serendipity 1.0.2 fixes XSS vulnerability

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 19 Oct 2006 19:01:35 +0200

Hallo Dirk, zu Deinem Artikel möchte ich noch hinzufügen, dass Serendipity 1.0.2 ein Security-Update ist, das XSS Vulnerabilities behebt.

Man möchte dieses Update also nicht verzögern, sondern unverzüglich installieren!

What is REQUEST_URI supposed to be?

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Tue, 12 Sep 2006 16:01:46 +0200

While evaluating Gallery, I noticed that my test web server generates wrong links inside the web application. After getting some help on the Gallery Forum, I was told that this was because my setup was miscreating REQUEST_URI to contain the entire URI, consisting of scheme, host name and path, while Gallery expects that variable to be only the path portion of the URI.

Since REQUEST_URI is fine when I ask the web server running the application directly from the host in question, while accessing it from my local machine through an ssh tunnel (since the application web server is not going to be publicly visible on the Internet) yields the full URI in REQUEST_URI

Unfortunately, neither is the PHP Documentation especially verbose (it just says that REQUEST_URI is “The URI which was given in order to access this page; for instance, ‘/index.html’.”) nor is the apache documentation formally defining REQUEST_URI (the closest to a definition being the documentation for mod_setenvif, which says that REQUEST_URI is “generally the portion of the URL following the scheme and host portion without the query string”).

Did I miss a more formal documentation of apache/PHP’s behavior? Pointers appreciated.

While I was writing this blog entry, which was a lot more angry in its first version, the Gallery guys finally acknowledged that apache and PHP are not sufficiently specifying REQUEST_URI and that I have delivered a valid example where there is a host part in REQUEST_URI. They’re going to work around this. Good news, thanks!

The promised fix is in gallery2 svn, I have applied the patch to my local version, and the application is fine now. Thanks!

Comments to this article were closed in July 2012, this article is getting an obscene amount of spam

Trennung von Webapplikationen mit Extrainstanzen des Apache

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sat, 18 Feb 2006 16:21:24 +0100

Die Artikelreihe zum Thema “Trennung von Webanwendungen untereinander”, die mit fastcgi, suphp und zwei Artikeln über das klassische suexec begann, findet heute ihren vorläufigen Abschluss mit dem Setup, für das ich mich letztendlich entschieden habe.

Da auf dem von mir angepeilten Zielsystem nur eine Handvoll Präsenzen mit ähnlich wenigen verschiedenen Webanwendungen ins Hosting kommen wird, könnte ich mich für eine Lösung entscheiden, deren Skalierungsverhalten sie für “richtiges” Hosting uninteressant macht. Jede Webapplikation bekommt einen eigenen apache, der gleich unter einer nicht priviligierten uid gestartet wird und auf einem hohen Port von 127.0.0.1 Verbindungen annimmt. Das Mapping auf die “offizielle” IP und Port 80 übernimmt ein zentraler “normaler” apache als reverse proxy.

Dieser Artikel entstand ursprünglich im Jahr 2006. Fünf Jahre später hat auch Debian es geschafft, mehrere apache-Instanzen “ordentlich” zu unterstützen, und ganz ohne gepatchte Scripts. Diese überarbeitete Version dieses Artikels beschreibt die Vorgehensweise unter dem in 2011 aktuellen Debian squeeze.

Das ganze Verfahren unter Debian stable mit apache2 zu implementieren war verhältnismäßig einfach. Ich habe mich bemüht, die Arbeit der Debian-Maintainer so weit wie möglich zu nutzen, da mir das Packaging von apache2 außerordentlich gut gefällt. Also sind ein patch gegen apache2ctl, ein kompletter Rewrite von a2[en|dis][mod|site] und ein severely patched initscript dabei rausgekommen, mit deren Hilfe das Management der vielen verschiedenen Apaches einfach geworden ist. Debian hat meine Patches natürlich nicht 1:1 übernommen, aber inzwischen geht es auch ohne gepatchte scripts.

Auf dem Zielsystem setzen wir das Verfahren wie folgt ein:

Jeder Apache bekommt einen eigenen Unix-User (user-appname) mit eigenem Homedirectory.
In diesem Homedirectory kann der User nicht schreiben, die Dateien dort gehören user:user-webapps
unter /home/user-appname/apache wird eine abgespeckte Apache-Konfiguration hinterlegt, in der auch konfiguriert ist, dass der apache untr dem Account user-appname laufen und auf einem hohen Port unter 127.0.0.1 horchen soll.
Diese Konfiguration wird nach /etc/apache2-user verlinkt
Ein spezielles Initscript /etc/init.d/apache2-user wird aus /usr/share/doc/apache2.2-common/examples/secondary-init-script (z.B. mit /usr/share/doc/apache2.2-common/examples/setup-instance) erzeugt
Mit insserv apache2-user wird das Initscript aktiviert und an der passenden Stelle in die dependency-based Bootreihenfolge eingehängt
Die Applikation liegt in /home/user-appname/applikation.
Apache-Module lassen sich mit dem erweiterten a2enmod einfach lokal aktivieren.
Der Apache lässt sich dann mit dem erweiterten Initscript einfach unabhängig von den anderen apaches starten.
Der “Haupt-Apache” wird per ProxyPass und ProxyPassReverse so konfiguriert, dass Zugriffe auf den entsprechenden Namensraum zum “richtigen” User-apache weitergereicht werden.

mod_rpaf sorgt in den Applikations-Apachen dafür, dass die vom Proxy übermittelten Client-IPs in den Logs landen und IP-basierte Auswertungsmechanismen (z.B. zur Spamabwehr) funktionieren.

Auf diese Weise ist sichergestellt, dass die Webapplikationen getrennt voneinander laufen. Per Rechtevergabe im Dateisystem kann man nun erreichen, dass eine Webapplikation nur dort lesen und schreiben kann, wo es unbedingt notwendig ist. Die apache-Konfiguration kann entsprechend abgespeckt sein.

Diese Lösung hat natürlich auch ein paar Nachteile, zum Beispiel den exorbitanten Speicherbedarf duch die wirlich vielen apache-Prozesse im Speicher und die Tatsache, dass manche Webapplikationen sich herausgefordert fühlen, wenn plötzlich Portnummern in den URLs stehen und der Client mit anderen URIs kommt als man selbst weggeschickt hat. Weitere Nachteile sind mir in den fünf Jahren, die das Setup auf dem Zielsystem so bereits in Verwendung ist, bis heute nicht aufgefallen.

Wenn die Applikation Cookies benutzt, ist zu beachten, dass die Applikation ihre Cookies mit einer Domain versieht, und zwar in der Regel mit 127.0.0.1:x, weil der Applikations-Apache nicht weiß, unter welchem Domainnamen der Server letztendlich läuft. Das hat mich mit meinem Blog einige Tage Debuggingarbeit gekostet, und ohne die Hilfe von Garvin, Isotopp, Rince und anderem wäre das niemals erfolgreich gewesen.

Die Lösung ist in der Konfiguration des Reverse Proxy:

ProxyPassReverseCookieDomain 127.0.0.1:1312 blog.zugschlus.de 
ProxyPassReverseCookieDomain 127.0.0.1 blog.zugschlus.de

Der doppelte ProxyPassReverseCookieDomain ist nötig, weil aus irgendwelchen gründen manche Cookies mit und manche ohne Portnummer gesendet werden.

fastcgi

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Fri, 30 Dec 2005 14:18:31 +0100

In Fortsetzung der Artikelreihe zur Entfernung von PHP-Scripts aus dem Accountkontext des Webservers ist heute FastCGI an der Reihe.

Kurzzusammenfassung aus der Theorie: Es ist vermutlich performanter als suexec und suphp, bringt aber weder Erleichterung in der Handhabung noch in der Sicherheit.

In diesem Artikel bekommt auch das debianhowto.de apache2-php-fcgi-HOWTO sein Fett weg.

Auf der Suche nach Dokumentation zu diesem Thema landet man recht schnell beim
debianhowto.de HOWTO für apache2 mit PHP 4/5 als FastCGI. Mit den Jungs von Debianhowto bin ich ja in der Vergangenheit schon einmal aneinander geraten, aber im Vergleich zu diesem Machwerk ist das exim4-vexim-HOWTO gerade noch harmlos.

Das HOWTO ist ein reines HOWTO im “übelsten” Sinne: Es wird mit kaum einem Wort erklärt, was die 1:1 abtippbaren Dinge überhaupt machen. Damit mag man vielleicht schnell ans Ziel kommen, aber sobald man aus irgend welchen Gründen vom Weg des HOWTO abweichen muss, wird man mangels Hintergrundwissen auf die Schnauze fallen. Einige Fallen sind zwar im HOWTO erwähnt, aber ich finde es sportlich, dass man davon ausgeht, dass jeder, der jemals in Zukunft mit dem so eingerichteten System arbeiten wird, auch mit dem HOWTO vertraut ist.

Vorteile von PHP per FastCGI:

PHP mit FastCGI ist thread safe, das apache2 worker-mpm wird einsetzbar.
Dadurch, dass - wie bei mod_php - der PHP-Interpreter geladen bleibt, ist die Performanz besser als bei suexec oder suphp, wo der PHP-Interpeter als CGI läuft und für jeden Aufruf neu geladen und initialisiert werden muss. Bei FastCGI erfolgt dies allerdings nicht auf einer per-Webserver, sondern auf einer per-Vhost-Basis, so dass die geladenen Interpreter mit den richtigen Benutzerrechten laufen können.

Nachteile

mod_fastcgi steht unter einer seltsamen Lizenz, die im Debian-Projekt unter non-free geführt wird. Das bedeutet, dass es für mod_fastcgi nicht den aus Debian gewöhnten guten Support gibt.
Der Benutzerkontextwechsel wird mit mod_suexec erreicht und hat somit alle Nachteile, die suexec mit sich bringt.
mod_fastcgi ist in der Version 2.4.2 (Debian stable, testing, unstable, Stand 2005/12) fehlerhaft und funktioniert nicht mit apache. Es ist also derzeit der Einsatz eines Development-Snapshots notwendig. Wirklich maintained sieht mod_fastcgi ausserdem nicht aus, der letzte Release ist aus dem Jahr 2003, der “aktuelle” Development-Snapshot aus dem April 2004.

Probleme, die ich mit dem HOWTO sehe

Die Zusammenhänge werden so gut wie gar nicht erklärt.
Ebenso wird nicht erklärt, was die einzelnen Konfigurationsschritte nun wirklich tun.
Es wird genau erklärt, wie man sich ein eigenes PHP5 baut, ohne dass darauf hingewiesen wird, dass man auf diese Weise den Support von Debian verliert. Immerhin wird der User dazu angehalten, sein lokales PHP nach $HOME zu installieren, und bei der Anleitung zur Installation der inoffiziellen PHP5-Pakete fehlt auch der Hinweis auf den mangelnden Security-Support nicht.
Die Aussage, dass es kein fcgi-enabletes php4-cgi in Debian sarge gibt, halte ich für falsch. Zumindest erhalte ich beim Aufruf von php4-cgi -i auf einem Debian sarge die Ausgabe “ServerAPI: CGI/FastCGI”.
Der “aktuelle” Development-Snapshot wird von den HOWTO-Usern ohne Sonderprefix unter Umgehung des Packagesystems direkt nach /usr geballert.
Weiter unten wird erwähnt, dass es in Debian sarge ein libapache2-mod-fastcgi gibt. Das ist allerdings genau die fehlerhafte Version 2.4.2, die laut der Aussage zwei Bildschirmseiten weiter oben “nicht funktioniert”, leider ohne weitere Erklärung des Fehlverhaltens.
Von a2enmod und a2ensite scheint der HOWTO-Autor nix zu wissen
Später wird mit dem Immuteable-Bit hantiert, und hier wird’s dann vollends gefährlich.
- Arbeitet man auf einem Filesystem, das das Immuteable-Bit unterstützt, ist die Aktion noch halbwegs sauber.
- Böse Falle für Leute, die später das System in die Hand bekommen ist, dass Kopieren des Dateibaums des virtuellen Hosts das Immuteable-Bit nicht mitkopiert. Sprich: In einem simpel mit cp -a kopierten Baum fehler dieses Bit auf den betroffenen Dateien, was ein riesengroßes Sicherheitsloch aufreißt. Das ist zwar im HOWTO klar erklärt, aber wie gesagt - derjenige, der den Dateibaum kopiert, muss nicht notwendigerweise das HOWTO gelesen oder gar verstanden haben.
- Für Filesysteme, die das immuteable-Bit nicht unterstützen, legt das HOWTO dem Benutzer nahe, suexec zu patchen, und liefert eine idiotensichere Anleitung mit, wie das getan werden kann. Dabei werden zwar die Debian-Sourcen verwendet, aber das entstehende Binary wird natürlich wieder manuell an die passende Stelle im Dateisystem geschoben - erneut unter Umgehung des Packagesystems. Ich möchte kein System in die Finger bekommen, das auf diese Weise so verhunzt wurde. Übel. Immerhin - das neu gebaute, unsicherere suexec wird nicht benutzt um das “Original-suexec” zu überschreiben, sondern erhält einen eigenen Dateinamen, suexec-fcgi, was den Knieschusseffekt dieser Operation wenigstens etwas dämpft.
Ich würde mich wundern, wenn die Verwendung von Documentroots ausserhalb /var/www für die Benutzer dieses HOWTOs funktioniert. Das Debian-suexec ist relativ strikt übersetzt, und dieser Fall ist im HOWTO mit keinem Wort erwähnt. Für Newbies - mithin die Hauptzielgruppe des HOWTO - ist das eine böse Falle.

Bitte, bitte, bitte. Lest Eure Texte bevor ihr sie veröffentlicht. Schreibt kurze, prägnante Sätze, vermeidet Umgangssprache, schreibt Zahlen zwischen eins und zwölf als Worte. Technische Dokumentation verdient besseres Deutsch!

Fazit: Debianhowto.de ist in meiner Achtung wieder ein Stück gesunken, die von mir erhoffte Standardlösung für ein Standardproblem habe ich immer noch nicht gefunden.

Demnächst in diesem Theater: Für jede PHP-Applikation einen eigenen Apache.

suphp

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sun, 11 Dec 2005 21:59:38 +0100

Schon bei den Vorarbeiten zu diesem und diesem Artikel hat man mir sehr nahegelegt, suphp anzugucken. Das habe ich heute getan.

Suphp kommt als Apache-Modul in der Debian-Package libapache2-mod-suphp daher. In Sarge ist eine 0.5-Version; in sid eine 0.6.0-Version, die zur Laufzeit flexibler konfigurierbar ist. Upstream hat vor zwei Wochen eine 0.6.1 released, die bisher noch nicht ihren Weg nach Debian gefunden hat.

suphp tut auf Anhieb das, was man von ihm erwartet: Das php-Script läuft mit den Rechten des Dateiinhabers. Die Überraschungen sind im Detail, und ich weiss noch nicht genau, was ich darüber denken soll.

suphp ist wie suexec ein suid root laufendes Binary, das seine Rootrechte - wie suexec - zuerst zum Zieluser fallen lässt, und dann den php4-Interpreter aufruft. Daraus folgt:

Der PHP-Interpreter läuft nicht als Apache-Modul

libapache2-mod-php kann raus. Beziehungsweise: Es muss raus, denn der Parallelbetrieb von mod-php und suphp ist nicht unterstützt. Es kann laut Aussage des Upstreams alles passieren. Also lieber nicht machen.

suphp ist erheblich weniger pingelig als suexec. Das erleichtert zwar die Arbeit erheblich, weil es sofort so tut wie erwartet, aber über den damit eingehandelten Sicherheitskompromiss muss ich mir erstmal klar werden.

Die bei suphp 0.5 mitgelieferte Dokumentation ist die vom Upstream, die davon ausgeht, dass das Modul mit --with-setid-mode=force oder =paranoid übersetzt wurde. Die Debian-Package ist aber mit --with-setid-mode=owner gebaut. In der Folge führt die Beachtung der Anleitung zu einem nicht mehr startenden Apache, weil das mit =owner gebaute apache-Modul die Direktive suPHP_UserGroup nicht kennt und einem somit spontan um die Ohren fliegt wenn man die Anleitung befolgt.

suphp 0.6 ist zur Laufzeit besser konfigurierbar, was eventuell einen weiteren Sicherheitskompromiss bedeutet. Außerdem kann suphp 0.6 auch “normale”; CGI-Scripts ausführen und mutiert somit zum nahezu vollwertigen suexec-Ersatz.

Als Debian-Packages daherkommende Applikationen werden eher schwer unter suphp einsatzfähig sein, weil man die Dateien an einen anderen Benutzer “verschenken” muss. Ob das mit dpkg-statoverride einfach machbar ist, werden Experimente mit Dokuwiki in den nächsten Tagen zeigen.

Wie gut suphp für “normale” CGI-Scripts tut, werden Experimente mit munin-cgi-graph in den nächsten Tagen zeigen.

Momentan tendiere ich dazu, auch auf den sarge-Webservern einen Backport von suphp 0.6 einzusetzen, weil mir die Konfigurationsmöglichkeiten sexy erscheinen. Vielleicht komme ich irgendwann auch mal zu einer Meinung bezüglich der Sicherheitskompromisse. Jedenfalls steht die Kommentarfunktion dieses Artikels bereit, und ich freue mich auf Eure Meinungen.

Nachtrag

Nachdem ich Ende Dezember einige Fragen auf der suphp-Mailingliste gestellt habe, und diese Fragen genauso wie die explizite Nachfrage beim Autor drei Wochen später unbeantwortet verhallten, habe ich die Experimente mit suphp abgebrochen.

suexec, die nächste

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sun, 27 Nov 2005 11:27:02 +0100

In Fortsetzung von suexec my php, baby^wapache habe ich gestern suexec auf dem ersten Produktivsystem verfügbar gemacht, und einige Unzulänglichkeiten im Debian-Setup gefunden.

Die Umstellung des Zielsystems von apache auf apache2 ging erschreckend schmerzfrei vonstatten. Die einzige Falle dabei war, dass einige Dinge (z.B. der ScriptAlias auf /usr/lib/cgi-bin) bei apache in der Serverkonfiguration steht, bei apache2 aber (IMO sinnvollerweise) in den virtual host geschrieben werden muss. Es waren also minimale Änderungen an der kopierten virtual-host-Konfiguration notwendig.

Dann suexec. Ich bin natürlich wieder in die Falle getappt, dass ich erwartet habe, dass das cgi mit den Rechten des Fileowners läuft, und ich habe wieder übersehen, dass suexec ein eigenes Log (/var/log/apache2/suexec.log) schreibt. Als nächstes musste ich die userbezogenen virtuellen Hosts von ~user/.www/www.virthost.example nach /var/www/virtual-hosts/user/www.virthost.example verschieben, da Debians suexec nur cgi-bins aus /var/www suexecen mag. /var/www/virtual-hosts muss man dann in der Konfiguration für den default virtual host auf “deny from all” setzen, damit man die Inhalte der virtual hosts nicht zusätzlich noch über den default virtual host erreichen kann. Das ist auch der Grund für die dazwischen eingeschobene Verzeichnisebene.

So weit, so gut, für die cgi-bins der Benutzer.

Nun möchte ich allerdings, wenn ich schon suexec am Start habe, auch gerne die aus Debian-Packages kommenden cgi-Scripts suexecen. Und das ist ein Punkt, wo ich vorerst bei einem knackingen “geht nicht” angekommen bin.

suexec suexect nur, was in /var/www liegt. Debian-Packages werfen ihre cgi-scrips aber nach /usr/lib/cgi-bin

suexec kann für jeden Virtual Host nur auf einen User suexecen. Bei den Scripts aus Debian-Packages wäre es aber sinnvoll, unterschiedliche Scripte auf unterschiedliche User zu mappen.

Also wird man wohl in den sauren Apfel beissen und sich darauf verlassen müssen, dass das, was aus Debian-Packages kommt, hinreichend sicher ist, dass man es mit den Rechten des Webservers laufen lassen kann. Auch wenn das bedeutet, dass einige Logs für www-data writeable sein müssen, was ich persönlich so richtig ätzend finde.

suexec my php, baby^wapache2

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sat, 08 Oct 2005 01:47:00 +0200

Von einem der auszog, seine PHP-Scripts nicht mehr als www-data laufen zu sehen.

Auf der Suche nach einer Lösung für ein Standardproblem

Während meiner ISP-Zeit habe ich es nur in zwei Bereichen geschafft, den Rat eines Kollegen (“Du kannst Dich nicht mit allem auskennen”) zu beherzigen: Webserver und RADIUS. Der bewusste Verzicht auf RADIUS-Kenntnisse wäre heute im ISP-Bereich ein Hindernis, und Webserver-Knowhow versuche ich derzeit durch kleinere private Projektchen aufzubauen.

Eins dieser Projektchen war der Bau eines Webservers, bei dem PHP-Scripts nicht mit den Rechten des Webservers laufen, sondern mit den Rechten des Benutzers. Auf Servern, bei denen die Betreiber der virtuellen Server sich nicht gegenseitig vertrauen, ist das eine Grundanforderung, die gar nicht sooo leicht zu befriedigen ist. Apache bringt zwar schon seit geraumer Zeit suexec mit, das eigentlich genau diese Aufgabe erledigen soll. Allerdings arbeiten die großen Hoster teilweise aus historischen Gründen mit grotesk gepatschtem suexec, so dass man die Berichte, die man aus diesen Ecken bekommt, für ein privates Feldwaldundwiesenprojekt nicht umsetzbar sind. Die im Web ergooglebaren Dokumentationen sind allesamt durchwachsen, und nicht selten so voller Widersprüche, dass man am besten mit dem Lesen aufhört, ehe man völlig verwirrt ist.

Kurze Recherche zeigt, dass suexec sowieso ein Auslaufmodell ist. Irgendwann wird apache2 mit dem perchild threaded model so weit sein, dass für jeden virtuellen Host ein eigener Apache-Prozess mit den entsprechenden Rechten läuft, was alle heuten Probleme lösen dürfte. Aber, “This MPM is not currently expected to work correctly, if at all.” Also lieber erstmal die Finger weg. Den Spezialfall PHP bekommt man heute mit suphp erschlagen, aber das ist ein Projekt für die nächsten Tage. Mein aktuelles Vorhaben war, die Geschichte von der Pike auf zu lernen, und das heißt definitiv klassisches suexec.

suexec ist ein Wrapper für CGI-Scripts, der vom Apache aufgerufen dank suid root erstmal seine Privilegien eskaliert, nach Prüfung einer ganzen Latte von Preconditions seine Rechte auf die des “target users” reduziert und schließlich endlich das CGI-Script aufruft. Nun, wenn ich hier von CGI spreche, meine ich auch CGI. Da perl und php normalerweise als Apache-Modul gerufen werden, kann man da nicht mit suexec eingreifen. Also muss man die Scripts als CGI aufrufen, was zu einem Performanceverlust führt. Das machen die großen Hoster auch nicht anders, also ist dieser Weg so verkehrt nicht.

Also: mod_php raus, php4-cgi installiert und die (einfache) Konfiguration für “PHP als CGI” durchgeführt.
Dabei fällt schon auf, dass die apache2-Packages von Debian ziemlich schlau gebaut sind: Jede Apache-Erweiterung bringt in ihrer Package entsprechende Konfigschnipsel mit, die der Administrator mit den Scripts a2{en|dis}{mod|site} ein- und ausschalten kann. Gute Arbeit, das fühlt sich viel besser an als die wilden Debconf-Orgien (“Pondering....... Doing Magic......”) der apache-1.3-Packages. Ist halt wieder eine typische Debian-Geschichte mit vielen kleinen Dateien, die apache aber dank seines flexiblen Konfig-Parsers automatisch zusammenstellen kann; update-apache2.conf gibt es - glücklicherweise - nicht. Kris wird dieses Setup sicher nicht gefallen, ich mag es. Schön finde ich auch, dass suexec, das sehr stark zur compilezeit konfiguriert wird, in der Debian-Package sinnvoll parametriert daherkommt.

Die CGIs im Userdir ~/public_html laufen auf Anhieb unter meinem User. Allerdings ist’s etwas komplexer, das auch ausserhalb des Userdirs hinzubekommen. Ursache dafür ist, dass ich mir selbst ein Bein gestellt hatte. Ich ging fälschlicherweise davon aus, dass auch ausserhalb des Userdirs suexec seine Rechte auf die des Users fallen lässt, dem die Datei gehört, in dem das CGI-Script steht; sozusagen ein auf den Webserver übertragenes suid-bit. Das stimmt aber nicht: Für suexec ausserhalb des Userdirs muss man innerhalb der Definition des virtual hosts explizit mit der Direktive SuexecUserGroup einen Target-User und eine Target-Group angeben, sonst fällt suexec transparent und kommentarlos auf den Fallbackuser zurück, der www-data heißt und man somit der Meinung ist, dass das suexec gar nicht aufgerufen würde. Nachdem dies endlich verstanden war, war der Weg zum ersten als mh laufenden CGI aus /var/www nicht mehr weit.

PHP als CGI unter suexec ist ein bisschen schwieriger. Bei einem über eine Action aufgerufenen php zählt nicht der Ablageort des PHP-Scripts, sondern der Ablageort des PHP-Binaries - und das liegt natürlich bei Debian weder innerhalb des Webspaces, noch gehört es dem richtigen User. Also wird man für jeden User, der PHP verwenden wird, ein eigenes PHP-Binary innerhalb des Webspaces brauchen, das obendrein auch noch dem richtigen User gehören muss. Ausserdem braucht’s wohl noch eine passende Action-Direktive für jeden Virtuellen Host; das hab ich allerdings noch nicht ausprobiert, weil ich immer nur mit einem virtuellen Host gearbeitet habe. Kaum macht man’s richtig, funktioniert’s auch schon, und mein passthru(“id”) sagte ordentlich id=1001(mh). Erfolgserlebnis.

Was lernen wir daraus: Auch wenn man erwartet, zu wissen was in der Doku steht, kostet Querlesen gerne mal einen Tag Zeit, weil man die wichtigen Informationen mehrfach überliest. de.comm.software.webserver ist für Fragen dieser Gewichtsklasse überfordert, ausser Bastian Blank hat sich niemand zur Antwort auf meine Fragen motivieren können.

Dasselbe gilt für #apache in Freenode, dessen Niveau bedauernswert niedrig ist und wo die Leute größtenteils nicht einmal wussten, was suexec ist. Das beste Debugging-Tool ist nach wie vor strace, weil man damit dem Prozess so weit auf die Finger gucken kann, dass man irgendwann mal zu dem Schluß kommt “das ist aber nicht so wie ichs aus der Doku erinnere, lasst mal lieber genau nachlesen”.

Nächste Projekte: suphp, und dann endlich die erste eigene s9y-Testinstallation.