suphp
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.
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.
Comments
Display comments as Linear | Threaded
Sven Hartge on :
Da ich im nächsten Jahr den Homepage-Server meiner FH (derzeit Solaris 6 auf einer E150) durch ein leistungsfähigeres Modell (dann mit Debian) ersetzen darf, möchte ich dabei auch gleich das Rechte-Problem, das sich auf einem Shared-Server mit sehr vielen Benutzern automatisch ergibt, lösen.
Bisher habe ich deine Artikel über suexec und jetzt über suphp mit sehr viel Interesse gelesen, da mir darin exakt die Richtung gezeigt wird, die ich zu gehen gedenke und ich wäre daher sehr erfreut, wenn du deine Artikelserie zu diesem Themenkomplex fortsetzen würdest.
(Ich weiss, das war nicht ganz der Kommentar, den du wolltest
)
-thh on :
Nun ja, besser als mod_php mit "safe mode" dürfte suphp in jedem Falle sein.
Ich erwäge das auch und lese daher ebenfalls sehr interessiert mit.
Noch mehr als die Sicherheitsimplikationen würde mich BTW einerseits die Performance interessieren und andererseits die Möglichkeit, suphp mit fastcgi zu "koppeln" ...
Florian Laws on :
Warum eigentlich fastcgi? Bringt das Performance-Vorteile gegenüber PHP als Apache-Modul?
Marc 'Zugschlus' Haber on :
Wenn Du suphp benutzt, läuft das php nicht mehr als apache-Modul. Wenn ich das richtig verstanden habe, ruft das suphp-Apache-Modul das suphp-Binary auf, das suid root ist, dann seine Rechte auf die Rechte des gewünschten Zielusers fallen lässt, und letztendlich den PHP-Interpreter mit dem gewünschten Zielscript ausführt.
ixs on :
Auf Bitten von Marc, hier mal mein Kommentar aus dem IRC:
Der Unterschied zwischen ist suphp und suexec ist, dass suphp speziell für den PHP Einsatz gedacht ist. D.h. Variablen wie PHPAUTHUSER und PHPAUTHPW, die cgi-php normalerweise nicht exportiert, sind mit suphp verfügbar. Dies bedeutet, dass HTTP Authentifizierung mit relativ wenig Umständen auch mit suphp Möglich ist.
Ein weiterer Vorteil ist, dass getrennt werden kann zwischen exec-cgi Rechten und PHP Rechten in der httpd.conf.
Auch brauchen die PHP Scripte kein execute Bit mehr und auch kein #!/usr/bin/php-cgi (im Worstcase), was weniger Supportaufwand bedeutet.
Gerüchteweise soll suphp auch performanter sein als suexec, aber dies konnte ich nie wirklich verifizieren.
Chef on :
Also wenn SUPHP wirklich so funktioniert wie hier beschrieben, dürfte die Performanz extrem schlecht sein. So gesehen ist es für Produktionssysteme keine Alternative zu mod_php- oder FASTCGI/SCGI-Lösungen.
Marc 'Zugschlus' Haber on :
Meines Wissens verwenden die beiden größten Webhoster Deutschlands suexec zur Trennung der Webapplikationen der verschiedenen User auf der Shared-Hosting-Plattform.
So viel also zu "keine Alternative zu mod_php und FASTCGI".
laZee on :
"shared hosting" impliziert ja auch quasi keine Erwartungen an Performance. Für das schmale Geld wird sich da keiner beschweren. Über die Performance lässt sich imho nur deswegen, weil die größten shared-Hoster es einsetzen, nicht viel sagen.
fortrabbit-frank on :
Wir haben uns Aufgrund der höheren der Sicherheit, obwohl der schlechteren Perfomance dennoch für SuPHP entschieden, als günstige PHP-Lösung, ansonsten kommt FastCGI zum Einsatz: http://fortrabbit.de/blog/2010/06/sicheres-schnelles-php-hosting/