Die Legende vom safe_mode

[SCA]

Hallo allerseits

Immer wieder lese und höre ich, das Joomla! die Einstellung safe_mode=off benötigt, um sauber zu laufen.
Das ist schlicht und ergreifend Unsinn, sofern der Server sinnvoll konfiguriert ist.

Ich hoste nun schon seit geraumer Zeit viele Joomla!-Projkte und bei allen ist der safe_mode=on eingestellt.
Es gibt kein einziges Problem damit.

Die Installation wird mit dem Installer durchgeführt und fertig ist das Joomla!
Es müssen keine unsicheren Dateirechte eingestellt werden und es muss kein safe_mode-Patch installiert werden.
Die User können den vollen Funktionsumfang im Backend nutzen und jede Kompomente installieren. Auch so "kritische" wie zoom-G. oder den PHP-Shop lassen sich ohne Probleme installieren und nutzen.
Es ist auch überhaupt kein Problem, trotz safe_mode=on Zugriff auf externe Programme wie ImageMagick, tar, touch, jhead, jpegtran und anderen zu gewähren.

Ich weiss nicht, woher diese Legende um den safe_mode-Patch rührt. Vermutlich von vielen Usern auf schlecht konfigurierten Hosting-Servern... wer weiss.

[de]

Das ist leider keine Legende...

Es liegt allerdings auch nicht direkt an dem Safe Mode... sondern in Verbindung mit dem Datei-Besitzer... darueberhinaus gibt es kann man den Safe Mode unterschiedlich konfigurieren. Leider ist die gaengige konfiguration so, dass der Zugriff auf Dateien/Verzeichnisse eines anderen Benutzers beschraenkt sind... so kann man z.B. keine Datei in einem Verzeichnis eines anderen Benutzers erstellen. Wenn dann (wie es meistens der Fall ist) nicht der FTP-Benutzer sondern der Apache-User Eigentuemer der Dateien wird kommt es halt zu den Problemen. Der Safe-Mode patch umgeht das, in dem der FTP-Account bei der Installation mit verwendet wird.

Also leider kein Unsinn... als Unsinn wuerde ich eher die leider zu gebraeuchliche Server-Konfiguration bezeichnen... was ja bei dir offenbar nicht der Fall scheint.

[SCA]

Mit "Unsinn" meinte auch letztlich diese Konfigurationen...

Nebenbei:
Wie betreiben PHP als Modul UND als CGI-Version (nach Wunsch des Kunden).
Die CGI-Version ist "kundenfreundlicher", denn dort ist der PHP-User identisch mit dem System-User eines Webs (also dem FTP-User). Dort gibt es null-problemo mit safe_mdoe=off. Es wäre fatal, den safe_mode dort zu deaktivieren und eventuell auch noch den exec()-Befehl zuzulassen. Schon liegen alle Kundendateien zur Spionage offen... In den Standardumgebungen läßt sich nur mit dem Safe_mode der exec()-Befehl auf bestimmte Verzeichnisse beschränken und damit "sicher" machen.
Auf exec() zu verzichten, bedeuted aber erst recht Probleme mit vielen anderen Scripts (Typo3 etc.) zu provozieren. Deshalb wäre ein Verzicht auf exec() sehr fatal. Viele Hoster machen safe_mode=off und verbieten exec() ... *kopfschüttel*


Bei PHP als Apache-Modul kann man Joomla! auch mit dem Apache-User installieren. Das überläßt man am besten dem Hoster oder aber man installiert sich erst einen PHP-Fileexplorer und lädt damit die Joomla-Dateien hoch, statt mit FTP. Damit ist das Thema dann auch erledigt, allerdings für Laien schwieriger zu lösen.


Fazit:
Es ist aus Kundensicht "schön bequem" wenn ein Hoster alle Restriktionen einfach abschaltet - wenn es nicht stört das dann die Daten für alle User auf der Host offen liegen


Und vielleicht ein Nachwort:
Der häufigste Grund, warum Hoster PHP als Modul installieren ist der, das sich damit viel mehr Kunden auf einem Server hosten lassen. Hier geht es ganz klar um Geld. PHP als CGI ist i.d.R sehr resourcenfressend und erfordert hohe Investitionen in Serverhardware.

[Lockhead]

Was ich an diesem beitrag aber nicht gut finde ist die tatsache das sich das alles nach Werbung anhört...

Denn du sprichst immer von den anderen die die Fehler machen und von dir selbst der alles richtig macht.
Meiner Meinung nach gehört dieses Topic hier gelöscht, denn die Informationen über den Safe-Mode und die konfiguration von Webservern in Verbindung mit PHP unter Beachtung von Sicherheitsrelevanten Gesichtpunkten kann man auch anders formulieren.

[SCA]

Naja, Werbung hin oder her. Ich muss auch das recht haben hier was scheiben zu dürfen...
Habe keine Lust, mir extra für solche Beiträge einen "Privat-Account" anzulegen.
Ich spreche keine Konkurrenz konkret an sondern beschreibe nur, wie diese Problematik um den safe_mode besser gelöst werden kann.
Es gibt hier mehrere Joomla-Hoster die laufend posten und keiner schreit gleich nach Löschen wg. Werbung. (Ich bin hier eher sehr zurückhaltend, wie man feststellen kann.)

Mein Posting hat auch einen Anlaß: Im rootforum.de habe ich von einem Redakteur gelesen, der gerade im neuen Joomla-Magazin einen Artikel vorbereitet und daher die Hoster-Scene um die besten Einstellungen befragte. Fazit war wieder mal: safe_mode MUSS(!) off sein.
Das sind einfach Fehlinformationen auf Kosten der Sicherheit.
Ich denke, das darf man ruhig schreiben, erst recht wenn es bessere Lösungen gibt.

[Lingtyp]

SCA,

könntest du bitte mal hier deine Meinung sagen:

http://forum.joomla.org/index.php/topic,25839

Das würde sicher helfen!

[SCA]

SCA,

könntest du bitte mal hier deine Meinung sagen:

http://forum.joomla.org/index.php/topic,25839

Das würde sicher helfen!

Dort ist PHP5 als CGI installiert. Das bedeuted nicht automatisch, das PHP-Dateien nur in dem cgi-bin-Verzeichnis ausführbar sind.
Im Normalfall sind sie das NICHT! Das cgi-bin-Verzeichnis ist für Perl-Dateien oder teilw. auch Binaries (als CGI kompiliert) oder Shell-Scripte (wenn zugelassen) reserviert.
Es gibt PHP-Installationen, die die Ausführung in den cgi-bin-Verzeichnissen erfordern. Das ist eine anwenderunfreundliche Methode und hängt mit dem verwendeten wrapper zusammen. Kann nur der betreffende Hoster beantworten. Im vorliegenden Fall scheint es so zu sein, denn der angegebene Link http://www2.ku.edu/~mattg/cgi-bin/phpinfo.php befindet sich ja auch dort.

Überlicherweise sollte man aus Sicherheitsgründen in cgi-Verzeichnissen keine Dateien direkt vom Browser ausgeben lassen dürfen (Mischbetrieb). Viele Scripte (vor allem Perl) speichern wichtige Daten in lesbaren txt-Dateien, die man dann einfach auslesen könnte. Falls im betreffenden Fall "Mischbetrieb" erlaubt ist, könnte man Joomla im cgi-bin-Verzeichnis installieren. Wenn nicht, dann muss man alle NICHT-PHP-Dateien auslagern, also eine ganz andere Verzeichnisstruktur aufbauen. Dort wird dann Joomla nicht sinnvoll funktionieren - wenn man es überhaupt zum Laufen bringt (wenn Mischbetrieb nicht erlaubt ist).

[Lingtyp]

Sowas dachte ich mir schon. Danke!

[KaNiko]

Was ich an diesem beitrag aber nicht gut finde ist die tatsache das sich das alles nach Werbung anhört...
....

Òla... kleine Zwischenbemerkung!
Ich sehe das nicht als Werbung, sondern endlich jemand, der hier mal Lösungsansätze von sich gibt.

Und wenn ich das richtig verstanden habe, ist das auch das berüchtigte wwwrun -Problem.
Ich bin kein Hoster... weiss nur was in Confixx einzustellen ist, sqls anlegen FTP rumdüsen, usw.
Einer meiner Hoster ist zb http://www.net-housting.de für http://www.jug-berlin.de. Unschlagbar günstig und beim Support unglaublich flott.
Ist das jetzt Werbung? JA!  Na und?!

Gute Hoster müssen auch genannt werden. Und wer Lösungen im deutschsprachigen Bereich postet (und nicht gleich zum englishen weiterleitet) soll seinen Namen ruhig nennen dürfen.

Gruss
K.

Nachtrag: Jetzt weiss ich auch, wieso bei manchem Server das so eingestellt ist:

Und vielleicht ein Nachwort:
Der häufigste Grund, warum Hoster PHP als Modul installieren ist der, das sich damit viel mehr Kunden auf einem Server hosten lassen. Hier geht es ganz klar um Geld. PHP als CGI ist i.d.R sehr resourcenfressend und erfordert hohe Investitionen in Serverhardware.

[akede]

Hey,

nun ich sollte von der Legende wissen, oder?

Und laut meinen Infos ist es durchaus ein Problem.

Nun es gibt einen Weg drumrum, der hintergrund des Problems ist ja bei Safe-Mode, dass der Apache-User vom FTP User des Kunden abweicht. Damit stimmen die Dateirechte nicht überein und damit funktioniert eine nachträgliche Installationvon CMT's nicht mehr.

Das Problem muss da sein, sonst würden wir ja in die 1.1 nicht einen FTP Alternativweg einbauen, oder ;.-)?

Alex

PS-. mehr dazu wenn mein Sohn neben mir nicht "puter" ruft

Hallo allerseits

Immer wieder lese und höre ich, das Joomla! die Einstellung safe_mode=off benötigt, um sauber zu laufen.

Das ist schlicht und ergreifend Unsinn!

Ich hoste nun schon seit geraumer Zeit viele Joomla!-Projkte und bei allen ist der safe_mode=on eingestellt.
Es gibt kein einziges Problem damit.

Die Installation wird mit dem Installer durchgeführt und fertig ist das Joomla!
Es müssen keine unsicheren Dateirechte eingestellt werden und es muss kein safe_mode-Patch installiert werden.
Die User können den vollen Funktionsumfang im Backend nutzen und jede Kompomente installieren. Auch so "kritische" wie zoom-G. oder den PHP-Shop lassen sich ohne Probleme installieren und nutzen.
Es ist auch überhaupt kein Problem, trotz safe_mode=on Zugriff auf externe Programme wie ImageMagick, tar, touch, jhead, jpegtran und anderen zu gewähren.

Ich weiss nicht, woher diese Legende um den safe_mode-Patch rührt. Vermutlich von vielen Usern auf schlecht konfigurierten Hosting-Servern... wer weiss.

[Predator]

Kann eigentlich nur bestätigen, das PHP als CGI anders mit den Userrechten umgeht. Hab auf meinen Servern PHP als CGI installiert und nicht dieses Problem, da der Apache User Immer identisch ist mit dem richtigen User.

Sehe das ganze nicht so also Werbung, sondern eher als Info.

[SCA]

Nun es gibt einen Weg drumrum, der hintergrund des Problems ist ja bei Safe-Mode, dass der Apache-User vom FTP User des Kunden abweicht. Damit stimmen die Dateirechte nicht überein und damit funktioniert eine nachträgliche Installationvon CMT's nicht mehr.

Ja genau, bei abweichenden Usern und wenn das System dann diese Abweichung prüft, dann gibt es die Probleme.
Safe_mode abzuschalten, um dieser Prüfung aus dem Weg zu gehen, ist aber der denkbar schlechteste Weg, weil damit ein großes Stück Sicherheit aufgegeben wird (zumindestens solange PHP noch so wenig Sicherheitsfeatures bietet und es diesen safe_mode gibt. In Version 6 soll er ja endlich aufgegeben werden - aber dann wird es eben andere Mechanismen geben.)

Was muss man also versuchen?

--> Dafür sorgen, das PHP-User und System-User (FTP) identisch sind!

Wie macht man das?

1) PHP als CGI-Modul:
Hier kommen wrapper zum Einsatz, die serverseitig dafür sorgen, das PHP-Scripte mit dem Systemuser laufen. Dies ist der anwenderfreundlichste Fall - für die Hoster oft aber nicht der "lukrativste", weil damit die Serverlast stark ansteigt. Auswirkung: Weniger mögliche Kunden auf einem Server.

Gerne wird behauptet, das PHP als CGI langsamer ist. Das ist Quatsch! Die Scripte werden genauso schnell ausgeführt! Allerdings muss bei jeder Scriptausführung das PHP-Binary geladen werden und das erzeugt viel Overhead in Form von Speicher, Festplatten und CPU-Belastung. Das Laden selbst benötigt wenige Millisekunden und ist i.d.R. vom Webseitenbesucher nicht spürbar (vor allem mit PHP4, dessen Binary noch angenehm klein ist).

Nebenbei: PHP als CGI hat ggf. Nachteile für Einzelfälle: Es funktionieren dann ein paar Apache-Spezialitäten nicht (z.B. Header-Änderung, HTTP-Authentifizierung). .


2) PHP als Apache-Modul:
Die einfachste Art PHP zu installieren. Es wird quasi mit dem Apache zusammen gestartet. Der Apache stellt im Server immer eine vorher definierte Anzahl Prozesse in den Speicher. Diese warten dann auf ihren Einsatz und müssen nicht neu geladen werden. PHP ist dann schon mit "dabei".
Feine Sache, aber leider arbeitet PHP dann mit dem User des Apachen. Dieser ist i.d.R. serverweit derselbe (wwwrun, www-data, nobody und wie sie alle heissen), sofern man keine andere Techniken wie z.B. eine chroot-Umgebung für jeden Kunden einsetzt.

Um hier auch als Kunden (ohne Zugriff auf den Apache-User) Joomla! sinnvoll benutzen zu können, muss man dafür sorgen das Joomla! mit den Rechten des Apache-Users hochgeladen wird. Der Hoster könnte die Dateien zur Verfügung stellen oder aber man installiert sich zunächst einen File-Explorer (z.B. den Quix-Explorer http://quixplorer.sourceforge.net/) und lädt damit die Dateien für Joomla auf den Webspace. Danach kann man das Joomla-Setup problemlos ausführen.
Anschließend sollte man in Joomla dann die Jommla-Komponente dieses Explorers einbinden (http://developer.joomla.org/sf/projects/joomlaxplorer). Jezt kann man alle Dateioperationen (sofern überhaupt notwendig) innerhalb des Joomla-Verzeichnisbaum mit dem Explorer lösen. FTP hat hier nichts mehr zu suchen. Man hat dann einen homogenen Verzeichnisbaum, der unter den Rechten des PHP-Users angelegt wurde.


Fragen:

* Sind die Dateien nicht unsicher, wenn man im Fall 2) einen globalen User verwendet?
Nein, wenn man zusätzlich weitere Sicherheitsfeatures bei PHP aktiviert (z.B. das openbasedir).

* safe_mode=on verhindert aber uploads in Foren und bei Gallerien!
Nein, nicht wenn man uploads in der PHP-Konfiguration zuläßt und sinnvolle Werte für bestimmte Restrictions setzt.

* Die Menalto-Gallerie läuft nicht mit sf=on
Das ist korrekt! Die Menalto-Gallerie kann nicht benutzt werden. Das liegt aber nicht an Joomla oder der Bridge zur Gallery, sondern an der Gallery selbst. Leider gibt es heute immer noch Programme, die den sf=off zwingend benötigen. Hier muss man auf Konkurenzprodukte ausweichen. Bislang ist mir noch kein Jomla/Mambo-Modul über den Weg gelaufen der zwingend sf=off benötigt.

* sf=on verhindert den Zugriff auf weitere externe Programm (ImageMagick u.a.)
Ja genau, das soll ja auch so sein!!
Typische externe Tools können vom Hoster jedoch problemlos auch bei sf=on den Kunden zur Verfügung gestellt werden. Dazu kann man in PHP eigene Verzeichnisse definieren, die für diese Zugriffe freigeschaltet sind. Der Hoster muss deswegen diese Tools kein zweites mal installieren. Sie werden über Symlinks in das Verzeichnis gelinkt.

* Ich glaub das alles nicht, das das so einfach gehen soll!
Bei ernsthaftem Interesse und seriösen Anfragen, stelle ich gerne Demo-Accounts zur Verfügung (nach Fall 1).

* Warum gibt es dann so viele Probleme bei zig Hostern?
Darüber erlaube ich mir kein Urteil. Fragen Sie die Hoster.


Meines Erachtens sollte die Comunity eine Art "Zertifikat" verleihen oder eine Liste tatsächlich geprüfter Hoster zur Verfügung stellen, damit sich die potentiellen neuen Joomla-User besser orientieren können. Zu verbreiten, das der safe_mode zwingend auf "off" stehen sollte, ist jedenfalls der falsche Weg. Das führt nur dazu das laufend diese Wünsche an die Hoster weitergeleitet werden (ich bekomme fast täglich solche Anfragen) und diese dann denken, das sie nur Erfolg mit unsicheren Konfigurationen haben werden. So mancher Wohnzimmerprovider erfüllt nur allzu gerne die Kundenwünsche - wenn er dann mal einen Kunden abbekommt.

Ich führe noch viele Diskussionen in anderen Foren, auch einigen Webdesigner-Foren. Joomla! hat dort einen schlechten Ruf. Haupsächlich weil es keinen validen Code erzeugt und Tabellenstrukturen verwendend. Es ist dort immer dieselben Grundsatzdiskussion mit bestimmten Code-Fetischisten. Das Joomla! dann auch noch zwingend unsichere Servereinstellungen benötigt, ist oft ein weiteres Argument der Gegner. Es ist ein Kampf gegen Windmühlen... wenn dies selbst in der Joomla!-Community so kommuniziert wird. Das sollte die Community endlich richtig stellen!

[bon]

* sf=on verhindert den Zugriff auf weitere externe Programm (ImageMagick u.a.)
Ja genau, das soll ja auch so sein!!
Typische externe Tools können vom Hoster jedoch problemlos auch bei sf=on den Kunden zur Verfügung gestellt werden. Dazu kann man in PHP eigene Verzeichnisse definieren, die für diese Zugriffe freigeschaltet sind. Der Hoster muss deswegen diese Tools kein zweites mal installieren. Sie werden über Symlinks in das Verzeichnis gelinkt.

ich denke das ein symlink nicht funktionieren wird. die binarys müssen dem gleichen eigentümer/gruppe gehören wie der betreffende systembenutzer. zumindest beim apache-modul/open_basedir/sf=on.

ich schalte i.d.r. den sf aus und open_basedir ein. manche behaupten das wäre sehr unsicher aber bewiesen hats mir noch keiner :-)

p.s. dieses thema finde ich persönlich sehr interessant.
p.p.s als hoster sollte man beides anbieten ... den wenn mein programm in der cgi-umgebung nicht läuft (http_auth) nutzt mir eine mögliche joomla-installation auch nichts.

[SCA]

ich denke das ein symlink nicht funktionieren wird. die binarys müssen dem gleichen eigentümer/gruppe gehören wie der betreffende systembenutzer. zumindest beim apache-modul/open_basedir/sf=on.

Doch funktioniert definitiv! Bei CGI und beim Modul. Deswegen gibt es das ja überhaupt.
Die Binaries müssen in dem mit safe_mode_exec_dir in der php.ini defeinierten Pfad nicht dem Systembenutzer gehören. Ginge ja auch gar nicht, weil der Systembenutzer bei jedem anderen Kunden ein anderer wäre.

ich schalte i.d.r. den sf aus und open_basedir ein. manche behaupten das wäre sehr unsicher aber bewiesen hats mir noch keiner :-)

Probier aus:
exec("ls -l /etc/", $du);
var_dump($du);

oder:
exec("cat /etc/passwd",$output);
var_dump($output) ;

Mit 5 Zeilen Code kannst Du alle Systemuser auslesen, alle Verzeichnisse nach z.B. configuration.php durchsuchen und die dort im Klartext befindlichen Zugangsdaten auslesen...

Für vieles wirkt die basedir-Einschränkung gar nicht!
Natürlich kannst Du exec() verbieten, aber dann kannst Du gar nichts Externes mehr einbinden und noch weniger installieren. Ist also keine Lösung.

p.s. dieses thema finde ich persönlich sehr interessant.
p.p.s als hoster sollte man beides anbieten ... den wenn mein programm in der cgi-umgebung nicht läuft (http_auth) nutzt mir eine mögliche joomla-installation auch nichts.

Genau deswegen machen wir das so.... :-)

[bon]

ich schalte i.d.r. den sf aus und open_basedir ein. manche behaupten das wäre sehr unsicher aber bewiesen hats mir noch keiner :-)

Probier aus:
exec("ls -l /etc/", $du);
var_dump($du);

oder:
exec("cat /etc/passwd",$output);
var_dump($output) ;

Mit 5 Zeilen Code kannst Du alle Systemuser auslesen, alle Verzeichnisse nach z.B. configuration.php durchsuchen und die dort im Klartext befindlichen Zugangsdaten auslesen...

ok :-) das ist natürlich klar. nur stehen die passwörter verschlüsselt in /etc/shadow und die bekommst du damit nicht auf. natürlich ist es unschön zu sehen wie viele systembenutzer es gibt etc. aber für mich selbst oder leuten die sich gemeinsam einen server teilen ist das unwichtig.

fakt ist in jedem fall das php sich noch nicht sauber ins systemgefüge eingliedert. zu viele spagate sind erforderlich.
aber was ist schon perfekt in dieser welt ;-)

[Ch.]

Nebenbei: PHP als CGI hat ggf. Nachteile für Einzelfälle: Es funktionieren dann ein paar Apache-Spezialitäten nicht (z.B. Header-Änderung, HTTP-Authentifizierung).

Hallo zusammen!

Als Anfänger hätte ich zu obigem Statement noch ein paar Fragen:
Bedeutet das, mit fastcgi sind Anweisungen wie

Code: Select all

header('Location: http://www.example.com/');
header("Location: http://www.example.com/");
header('Content-type: application/pdf');
header('Content-Disposition: attachment; filename="downloaded.pdf"');

nicht mehr funktionieren (Stichwort: Header-Änderung)?

Ist mit "HTTP-Authentifizierung" folgendes gemeint?
http://www.php.net/manual/en/features.http-auth.php

Was sind weitere "Spezialitäten", auf die man verzichten muss?

Vielen Dank im Voraus. :)

Gruß,
Christian

[SCA]

1) Header:
Nein, das funktioniert.

2) HTTP authentication
Lies den ersten Satz auf der Seite auf die Du verlinkt hast.


Wir hosten nun schon über 2000 Joomla-Webs und bislang konnten wir keine Nachteile feststellen, die gegen "PHP als CGI" sprechen.

[Ch.]

Lies den ersten Satz auf der Seite auf die Du verlinkt hast.

Ups. Wer lesen kann ist klar im Vorteil... 

Wir hosten nun schon über 2000 Joomla-Webs und bislang konnten wir keine Nachteile feststellen, die gegen "PHP als CGI" sprechen.

Trotzdem würd mich interessieren, was die anderen "Spezialitäten" sind, von denen Du da gesprochen hast...
Schließlich ist Joomla nicht die einzige Anwendung, die mich interessiert...

Viele Grüße und schon mal ein riesiges Danke,
Christian

[SCA]

Lies hier:
http://de3.php.net/de/apache
ebenso (prinzipbedingt) ein persistente Datenbankanbindung

Man muss jedoch unterscheiden! Es gibt viele verschiedene Möglichkeiten "PHP als CGI" zu realisieren. Über suPHP beispielsweis funktioniert auch die Übergabe der HTTP-Authentifizierung an PHP.