Das versteht kaum Einer mehr, schon gar nicht ein Neuling.

Meinst jetzt den Abschnitt im Wiki oder das Folgende:

Das PHP "open_basedir" nun auf PHP_INI_ALL gesetzt hat, ist ein Armutszeugnis. Was hat ein Skript an der Grundkonfiguration zu ändern?

Nun ja. Wie dedlfix schon sagte, man kann die Schlinge enger ziehen. Die Sache ist letztendlich die: Man hat einen (virtuellen) Host, für den erst einmal eine bestimmte Konfiguration gilt.

Jetzt hat man da eine Webseite. Nehmen wir an, diese wird mittels eines CMS mit Inhalten gefüllt. Damit haben wir (genau genommen) mindestens drei Bereiche:

• Benutzerteil ("Die öffentliche Webseite")
• Bedienung des CMS
• Benutzeradministration für die Bedienung des CMS

Das trifft auch dann zu, wenn die Bedienung des CMS und die Benutzeradministration optisch(!) übereinstimmen oder gar, um den Aufwand zu vermeiden, vom Ideal abgewichen wird. Nehmen wir als Beispiel die Session. An eine solche werden im Beispiel höchst unterschiedliche Anforderungen zu stellen sein: Um im CMS eine Seite zu bearbeiten ("Bedienung des CMS ") muss man eine längere Inaktivität zulassen. Das ist aber hinsichtlich der Benutzeradministration des CMS aber gewiss keine gute Idee!

Damit sollte Deine Frage "Was hat ein Skript an der Grundkonfiguration zu ändern?" geklärt sein.

Kommen wir zum beklagten "Das versteht kaum Einer mehr, schon gar nicht ein Neuling."

Das ist halt so und ein Neuling kann nicht erwarten, dass mit einem einfachen make_safe(all.this); alle von ihm verursachten oder übersehenen Probleme erschlagen werden. Du hast ja gesehen, was für einen Aufwand man u.U. treiben muss um per GET übergebene Parameter zu bearbeiten, bis ein halbwegs sicheres include mit diesen möglich ist. In der Autowerkstatt wir man (ich weiß: das geschieht manchmal doch) auch nicht die Arbeit von Praktikanten und Azubis auf die Straße rollen lassen ohne die durch einen Facharbeiter oder Meister zu prüfen. Wenn die jetzt aber am Wochenende irgendwo rumschrauben und dabei Murks bauen, dann ist nicht der Werkzeugkasten, die Hebebühne oder das Schweißgerät schuld. Auf Deutsch: Wenn ein Neuling meint, er könne irgendwelches sicherheitskritisches Zeug programmieren, dann übernimmt er sich einfach.

Wie auch immer, es kann und wird erforderlich sein, dass die oben genannten 3 Bereiche eines CMS unterschiedliche Konfigurationen benötigen. Leider, und in dem Punkt hast Du recht, wird es völlig unübersehbar und letztendlich nervend, wenn man dann auch noch einen "shared host" hat, weil verschiedene Hoster (wohl infolge höchst verschiedener, von Kunden verursachter Katastrophen) höchst unterschiedliche Vorstellungen haben, was diese den Kunden erlauben und was nicht.

Beispiel:

Ich weiß zum Beispiel nicht so recht, was mein Hoster gemacht hat (oder ob das ein BUG in der verwendeten PHP-Version ist, aber [wenn ich im Login-System ein eigenes Verzeichnis für die Sessiondateien einrichte und dann die Session mit (http://wiki.selfhtml.org/wiki/PHP/Anwendung_und_Praxis/Loginsystem#Die_Ressource_logout.php)session_destroy() "kille"], bleibt das bei meinem Hoster (anders als auf allen meinen Testsystemem) völlig wirkungslos. Ich muss allen Ernstes mit:

unlink ( SESSION_FILE_DIR . '/sess_' . session_id());
#SESSION_FILE_DIR ist eigene Konstante

die Session-Datei quasi manuell löschen, was übrigens völlig undokumentiert ist.

Im Beispiel führt, wenn man das nicht bemerkt, genau das zu einem Sicherheitsproblem, weil das Abmelden völlig wirkungsfrei bleibt und die Sitzung selbst nach einem vermeintlich explizitem Logout weiter gültig bleibt!

Aber das ist halt so. Wenn in englischen Wagen das Lenkrad nicht da ist, wo ein Deutscher es erwartet, dann muss er eben nach dem Einsteigen und staunen nochmal rüberrutschen und schauen, wie er das mit dem Bedienkram hinkriegt...

Jörg Reinholz