phpBB.de

Mahlzeit geschätzte Gemeinde,

ich wollte mal eure Meinungen zu diesem Thema hören:

Ich habe kürzlich eine Neuinstallation eines plain-vanilla 3.0.6 gemacht. Während der Installation habe ich die config.php auf chmod 777 gesetzt, damit mir die Settings gleich auf dem Server geschrieben werden.
Das Board war fertig installiert, alles lief.
Nun war ich im ACP unterwegs, da kam der Hinweistext in der ACP Übersicht:

Deine Konfigurations-Datei (config.php) ist derzeit von jedermann beschreibbar. Es wird dringend empfohlen, die Berechtigungen auf 640 oder zumindest auf 644 (z. B.: chmod 640 config.php) zu setzen.

Ah, alles klar, stimmt, da war ja noch was. Also bin ich, ohne groß nachzudenken, bei gegangen und habe die config.php auf chmod 640 gesetzt.
Den Rest des Abends habe ich weiter die Basiskonfiguration gemacht, alles lief wunderbar. Ins Bett gegangen, nächsten Morgen das Forum aufgerufen:
Weisse Seite - nix ging mehr - keine Fehlermeldung, keine einzige Datei lieferte irgendwas aus, nur die weisse Seite, wie frisch gefallener Schnee.
What the heck? Plain-vanilla, nix gemoddet, alles Standard - da muss was am Server krumm sein (an die config.php habe ich nicht mehr gedacht). Merkwürdiger Weise liefen andere PHP Anwendungen. Long story short, ich erspare euch die weitere Fehlersuche.

Also: auf dem System, auf dem ich laufe, muss die config.php auf chmod 644 gesetzt sein. Also die Gruppe "other" lesenden Zugriff auf die config.php bekommen. Ansonsten passiert nix und man steht ziemlich blöd da. Zusätzlich: durch internes Caching auf dem Webserver (oder so) tritt das Problem zeitverzögert auf - nicht sofort. In meinem Fall erst mehrere Stunden später (reproduzierbar).
System: Apache 2.0 mit PHP Version 5.2.6-1 - nichts ungewöhnliches.
Warum nur eine weisse Seite kommt und keine Fehlermeldung, hat mein freundlicher Hoster folgendermaßen erklärt:

Der Webserver darf nicht darauf zugreifen da er im Hinblick auf die Datei zu "Others" gehört (Der Webservers gehört zur Gruppe www-data).
Es kann also nur über "chmod 0644 config.php" gehen.
Das ist die gängige Apache-Handhabe, von daher bezieht sich die Warnmeldung von phpbb wohl auf andere Systeme.

Und wir konnten auch das Mysterium "weisse Seite" klären.
Der PHP-Interpreter hat als er die Datei via require einlesen wollte einen error geworfen und das parsen abgebrochen. Daher kam der Parse-Fehler auch nicht zur Anzeige, da für die Auswertung von "ini_set('display_errors',1);" bereits der Interpreter zuständig ist, der garnicht zum Zuge kam.
Umgehen lässt sich das, indem require durch include ersetzt wird - was ich selbst nie tue da letzteres nur eine warning auslöst - aber genau dies würde jetzt eine Meldung anzeigen, da der Parser eben nicht gestoppt wird.

Nun meine Frage: ist das eine ungewöhnliche Konfiguration (das der Webserver zur Gruppe "other" gehört)?
Sollte es nämlich Standard sein, denn werden durch den Hinweis noch einige ziemlich böse in die weisse Seite laufen. Dadurch, das das Problem zeitverzögert auftritt und keine Fehlermeldungen ausgegeben werden, ist das auch ziemlich ätzend zu debuggen (haha). Und die meisten Webserver laufen auf dem Apachen.
Sollte dem so sein, dann sollte man wohl ernsthaft darüber nachdenken, die Meldung zu überarbeiten und nur chmod 644 zu empfehlen. Oder auf die potentiellen Probleme mit chmod 640 hinweisen.
Ein Fall für den Bugtracker auf phpbb.com? Oder bin ich mit dem System ein Einzelfall? Was denkt ihr?

Gruß

Kevin

Also ein Zeitversatz dieses Problems ist mir ehrlich gesagt noch nicht untergekommen. Eine Änderung der Dateirechte wirkt sich meines wissens sofort auf das Verhalten des Apache aus. Welche Konfiguration nun häufig ist und welche selten kann ich auch nicht sagen. Ich kenne sowohl die Kombination "Webserver ist in der gleichen Gruppe" als auch "Webserver gehört zu 'others'" (ich kenne auch "Webserver ist gleicher user", aber diese Variante halte ich für relativ unsicher).

gn#36 hat geschrieben:Eine Änderung der Dateirechte wirkt sich meines wissens sofort auf das Verhalten des Apache aus.

Könnten das nicht mal ein, zwei Leute auf einem Apachen in einem Testboard ausprobieren? Mal die config.php auf 640 setzten, abwarten und gucken was passiert.
Ich hab es nochmal in einem anderen Testboard gerade umgestellt - mal gucken wie lange es dauert - noch läuft alles normal...

Auf allen meinen Apaches wirkt sich eine Änderung sofort aus (5+ Stück auf unterschiedlichsten Plattformen, allerdings auch die meisten davon keine Produktivserver sondern Entwicklungsumgebungen), das bedeutet aber ja nicht dass es kein Caching geben kann, zumal das eigentlich ja sogar PHP cachen müsste da nicht Apache direkt sondern PHP, gestartet durch den Apache oder als Apache Modul, per include auf die Datei zugreift.

Danke gn#36!
Bei mir läuft das Testboard nach wie vor - schon über eine halbe Stunde. Als mir das passiert ist, habe ich auch noch mindestens 3 Stunden ohne Probleme weiter gearbeitet.
Interessant wäre es wenn mal Leute, die Shared-Webhosting haben, das mal testen könnten.

Aber wie auch immer: was meint ihr zu dem Hinweistext? Sollte der Hinweis auf chmod 640 nicht besser entfernt werden, oder ansonsten auf das potenzielle Problem hingewiesen werden?

*edit*
Ach ja, gn#36: du läufst bei 640 also auch in eine weiße Seite?

Das kommt auf die genaue Plattform an.

Lokal auf meinen Ubuntu Rechnern läuft der Webuser mit einer anderen Gruppe als ich, daher dürfte es einen Error geben (kann ich gerade nicht testen, ich gehe aber davon aus, da PHP so eingestellt ist, dass sämtliche Fehlermeldungen angezeigt werden sollten, also vor allem auch ein fehlgeschlagenes require). Auf einem OpenSuse Server hingegen habe ich einen Webuser mit passender Gruppe, aber anderem Besitzer, hier klappt 640 entsprechend genauso wie 644, selbiges gilt für einen Debian Server. In wiefern das nun spezielle Einstellungen sind die die jeweiligen Admins vorgenommen haben kann ich aber nicht sagen. Auf meinem Shared Webspace klappt zwar 640 nicht da hier die Konfiguration mit Gruppe und User nicht passt, aber ein Blank Screen gibt's auch nicht, da die PHP Fehlermeldungen aktiviert sind. Hier weist PHP also darauf hin dass es nicht ausreichend viele Rechte auf die Datei hat. In jedem Fall traten die Änderungen sofort ein, so dass eine eindeutige Fehlerzuordnung seitens des Admin möglich ist.

Windows Rechner fallen aus der Betrachtung natürlich raus, hier läuft das ganze ja völlig anders.

gn#36 hat geschrieben:Windows Rechner fallen aus der Betrachtung natürlich raus, hier läuft das ganze ja völlig anders.

Jo, nix chmod - Registerkarten Gepopel.

gn#36 hat geschrieben:Auf meinem Shared Webspace klappt zwar 640 nicht da hier die Konfiguration mit Gruppe und User nicht passt, aber ein Blank Screen gibt's auch nicht, da die PHP Fehlermeldungen aktiviert sind. Hier weist PHP also darauf hin dass es nicht ausreichend viele Rechte auf die Datei hat. In jedem Fall traten die Änderungen sofort ein, so dass eine eindeutige Fehlerzuordnung seitens des Admin möglich ist.

Ah - ok, interessant, das werde ich mal meinem Hoster mitteilen.
2,5 Stunden und mein Testboard läuft immer noch auf 640...

Was meinst du denn zu dem Hinweistext? Den so lassen? Könnte man es nicht auch verantworten nur zum 644 zu raten? Würde ja potentiellen Ärger vermeiden...

Ich finde es prinzipiell schon richtig 640 vorzuschlagen, denn wenn noch andere User auf dem Server sind die ein wenig mehr Zugriff auf ihr Konto haben und vielleicht nicht mittels chroot in ihr eigenes Verzeichnis eingesperrt sind, dann können die diese Datei auch lesen - und damit auf deine Datenbank zugreifen. In wiefern das so ist hängt natürlich davon ab ob es User mit mehr Zugriff auf den Server gibt oder geben kann - wenn man aber davon ausgeht dass dem so ist, dann ist 640 für deine Passwörter auf jeden Fall sicherer wenn es möglich ist. 644 hilft deiner Datenbank auch nicht wenn jemand fremdes auf die Datei Zugreifen kann - die Daten die in der Datei stehen haben ja auf die Datenbank auch Schreibzugriff - selbst wenn man also damit keine eigenen Skripte auf dem Server ausführen kann kann man doch andere Dinge mit den Daten anstellen. Gleiches gilt für einen Hackereinbruch - wenn der mit eingeschränkten Rechten reinkommt dann kann er mit 640 weniger anfangen als mit 644. Ich persönlich setze meine config.php sogar auf 44x (x = 4 oder 0 je nach Server), dann überschreibe ich die bei einem Update nicht aus versehen.

Danke nochmals, sehr erhellend!
Jut, um das abzuschließen: mein Testboard lief bis ich gestern gegen 23 Uhr ins Bett ging, heute Morgen kam die weiße Seite. Zurück ändern auf 644 wirkt sich sofort aus, das Board ist sofort wieder da.
Warum bei mir keine Fehlermeldung kommt, sondern nur der blank-screen, wurde von meinem Hoster recht einleuchtend damit erklärt, das man es möglichen Angreifern nicht einfacher machen möchte als nötig.

Gut, was tun? Ich denke man könnte vielleicht noch einen Hinweis mit in die ACP Meldung nehmen, das 640 Probleme bereiten kann. Aber ich mache da jetzt kein Fass (oder Ticket) auf - es reicht ja wenn ihr das beobachtet, ob dieses Problem überhaupt häufiger mal auftritt.

Gruß

Kevin

Klar, die Ausgabe von Fehlermeldungen nützt natürlich auch immer einem potenziellen Hacker.

Idealerweise loggt man die Fehlermeldungen und gibt sie nicht aus, so mache ich das beispielsweise bei meiner Website. Wenn irgendwas nicht klappt gibt es zwar trotzdem eine Meldung an den Benutzer, die enthält aber keine Details zum Problem, die Details werden stattdessen geloggt und ich kann sie mir jederzeit auch nachträglich ansehen. Das hat immense Vorteile wenn man von irgendwem eine Email bekommt dass irgendwas nicht funktioniert. Mit den groben Beschreibungen kann man ja häufig nicht mehr viel anfangen, aber im Log kann man dann nachsehen was tatsächlich für ein Problem aufgetreten ist (bei mir werden entsprechend vor allem auch eigene Fehlermeldungen erzeugt und geloggt, z.b. für fehlgeschlagene SQL Anweisungen u.ä.). Wenn man Zugriff auf seine php.ini hat kann man das Logging ganz gut einstellen, wenn nicht muss man eben schauen dass man das ganze in PHP implementiert (Stichwort error_handler) - das hat natürlich den Nachteil, dass es bei absolut grundlegenden Fehlern (Parse Errors u.ä.) nicht so klappt wie man das gerne hätte, denn dann kommt es überhaupt nicht soweit den eigenen Logging Code auszuführen.