Druckbare Version
Beim Systemcheck bekomme ich die Meldung, dass ich Fopen und Suhosin ändern soll.
Anhang 7806
Fopen ist kein Problem zu finden, unter dem Punkt Suhosin finde ich aber gleich mehrere Einträge und ich weiß nicht, um welche(n) es geht:
Anhang 7807
Da ich von den Einstellungen leider wenig Ahnung habe (und auch aus der Doku nicht schlauer werde), wäre ein Hinweis hilfreich.
Da muss ich jetzt auch mal nach haken!?
Warum Suhosin deaktivieren?
Suhosin ist eine Sicherheitserweiterung für PHP!
Deaktivieren bringt eine Schwächung des Systems.
Ich würde es eher begrüßen, das Modul entsprechend und nicht den Server einem Modul anzupassen.
Vielleicht bin ich paranoid, aber das wäre für mich ein Grund, dieses Modul vorerst zu meiden.
Meine bescheidene Meinung. ;)
Hallo Thomas,
Danke, jetzt habe ich wenigstens schon was dazu gelernt. ;)
Dann warst du wohl nicht dabei als ich auf der Konferenz die Extension vorgestellt habe? syncCto kommuniziert, verschlüsselt über einen API-Key und einem Diffie-Hellmann-Key, auf der HTTP-Ebene mit anderen Installationen. Und Suhosin ist (auf gut Deutsch gesagt) der dreckigste Sicherheitsmechanismus den man einem Server verpassen kann. Es schneidet einfach so willkürlich mitten in der Kommunikation ab und gibt keinerlei Feedback wo und warum. Das ist nicht entwicklerfreundlich, das ist unfähig. Ich nehme mal an das du unser "Modul" nicht kennst? Sonst wüsstest du das wir wirklich alles versucht haben um diese "Einstellung" vollkommen zu unterstützen. Eine Synchronisation ist möglich, wenn man aber eine Installation mit einer 120MB Datenbank und 100.000 Dateien hat, dann darf sich nicht wundern wenn dieses angebliche PHP-Sicherheitsfeature einfach mal einen Riegel vorschiebt.Zitat:
Zitat von Thomas
Aber wer im Jahr 2012 immer noch meint das suExec keine Option für ihn wäre, dem müssen wir leider im Systemcheck darauf hinweisen das es nun mal nicht möglich ist die Extension auf seinem Webspace zu betreiben. Suhosin fällt in die selbe Kategorie wie mod_security und Konsorten. Ich gebe mir ja wirklich die größte Mühe das syncCto selbst auf den billigsten 1&1 Servern funktioniert, aber ich muss mir wahrlich nicht anhören das man dann ja bitte das Modul meiden sollte. Beim besten Willen nicht. Ist ja nicht grade so als wären wir zu faul die Extension zu aktualisieren ;)
@jubel
In der neuesten Version die bald ins ER kommt werden zumindest rudimentäre Synchronisationen möglich sein, trotz Suhosin. Fopen benötigst du aber weiterhin, sonst könnten die Backups nicht funktionieren. Falls du keine Lust hast aufzurüsten oder es in deinem Fall nicht geht, versuch trotzdem mal eine Synchronisation. Wir sind immer mal wieder dran zu optimieren, manchmal erledigen sich dadurch wichtige PHP-Konfigurationen von selbst.
Nein hast du nicht. Vergiss das bitte ganz schnell wieder, Suhosin = böse, suExec = gut!Zitat:
Zitat von jubel
Mal auf gut Deutsch, mit diesen Angaben aus der phpinfo habe ich gleich doppelt ins Klo gegriffen?
- This server is protected with the Suhosin Patch 0.9.10
- allow_url_fopen: Off
Jein. Es werden bestimmte Funktionen nicht vollständig laufen oder besonders große Installationen werden einfach abbrechen. Kommt auf den Versuch an, aber wie es im Systemcheck schon steht: Die empfohlene Einstellung ist ...
Hast du es den schon überhaupt probiert?
Na ich werde es mal demnächst antesten. Das fopen OFF ist hatte mich auch gewundert, da ich ja ohne SMH laufe, vermutlich wegen mod_suphp.
Ich lasse Dich wissen wie es ausgegangen ist :D
Richtig, ich kenne die Erweiterung nicht, bisher war das auch nicht nötig.
Das spricht Euch auch keiner ab, im Gegenteil.Zitat:
Sonst wüsstest du das wir wirklich alles versucht haben um diese "Einstellung" vollkommen zu unterstützen.
Auf meinen Servern dürfte die Erweiterung mal generell nicht laufen.
Ich nutze Apache nämlich nicht! :)
Naja, ich möchte das philosophieren über den Apachen hier nicht anfangen. Der verbreitetste Server ja, aber mit Nichten der Beste. (Meine Meinung)Zitat:
suExec = gut
Und Suhosin als schlecht zu bezeichnen, dürfte auch etwas hinken. Zumal diese Erweiterung von einem ehemaligen PHP-Entwickler kommt, der seit Jahren die Sicherheit von PHP moniert und das schon aus aktiven Entwicklerzeiten. Ich denke mal nicht, dass dieser Umstand von Ungefähr kommt.
Ob das nun Entwicklerfreundlich ist oder nicht, ist mir als Serverbetreiber ziemlich egal. Ich werde sicherlich meinen Server nicht für einen Modulentwickler umstricken. Dann verzichte ich lieber auf das Modul.
Das würde ja auch bedeuten, dass ich einem Webspace-Anbieter bitten müsste, auf seinem Server Suhosin zu deaktiveren, nur weil ich dieses Modul nutzen möchte.
Genau dabei wirst Du vieler Orts auf taube Ohren stoßen.
Generell sehe ich aber, dass dieses Modul erst bei großen Datenbanken wirklich Sinn macht. Was den Schluss zu lässt, dass es auch kaum Sinn machen dürfte, eine Nutzung auf einem Webspace anzustreben. ;)
Wer diskutiert über den Apache, stand der hier jemals zur Debatte? ;)
Und eine Diskussion über Suhosin ist keine philosophische, sondern eine glasklare Faktenlage. Jeder gescheite Dev weiß das Suhosin murks ist, das ein "ehemaliger" PHP-Entwickler federführend war ist schon lange kein Qualitätsmerkmal.
Ne, aber suExec läuft nur unter Apache. ;)Zitat:
Wer diskutiert über den Apache, stand der hier jemals zur Debatte?
Ich möchte hier nicht streiten, aber Ihr lasst bewusst diverse Serverbetreiber außen vor und erwartet deren Verständnis. ^^
Bei Mehrheitsentscheidungen würde ich sagen, keine Chance.
@Thomas :
Das kann ich so nicht stehen lassen. Natuerlich muss man als Entwickler die Rahmenbedingungen festlegen, in welchen eine Erweiterung sicher laeuft.Zitat:
Ihr lasst bewusst diverse Serverbetreiber außen vor und erwartet deren Verständnis
So wie Contao auch nur mit PHP >=5 laeuft, und auch nur mit den freigegebenen Datenbanken. Das legt der Entwickler fest und fertig.
So haben die Entwickler des syncCto auch festgestellt, das es massive Probleme mit dem suhosin gibt. Und geben somit ihre Vorgaben vor.
So wie du auch den ER nur nutzen kannst, wenn Du SOAP im System hast.
Jedes System hat Vorgaben und Arbeitsbereiche in denen es sicher laeuft, deshlab kann ich deine Aussage ueberhaupt nicht verstehen und nachvollziehen.
Nur um nochmal eines Klarzustellen : suhosin kann sinnvoll sein, wenn man als Admin weiss, was man macht.
Die Defaulteinstellungen koennen in vielen Faellen sehr grenzwertig sein.
Nur als kleines Beispiel : Ein Formular mit EIngabedaten
Ich hatte mal ein Projekt, wo eine sehr komplexe Umfrage erstellt werden musste.
Suhosin hat mir meine eingegebenen Daten kommentarlos entfernt.
Warum ? Ganz einfach.
In der Standardeinstellung ist
So. Mein Formular hatte automatisch generierte Bezeichner mit stellenweise deutlich groesser als 64 Zeichen. Diese Variablen wurden automatisch aus dem POST Request entfernt.Code:suhosin.post.max_name_length = 64
suhosin.post.max_vars = 200
Selbiges fuer sehr komplexe Formulare, wo Teilbereiche basierend auf voreingestellten Bereichen ein- und ausgeblendet wurden.
Damit das klappte (ohne Ajax) musste das komplette Formular mit allen Feldern erstellt werden, was bei etwa 400 Feldern endete, und je nach Auswahl von Grundeinstellungen wurden andere Teilbereiche eingeblendet, und $Kunde konnte dort nun auswahlen treffen.
Es hat mich enorm viel Zeit gekostet, diese Fehlerquelle "suhosin" aufzufinden. Da es bei mir lokal funktionierte, online jedoch nicht.
Selbiges gilt auch fuer suhosin.cookie.max_name_length, der Standardmaessig auf 64 Zeichen begrenzt ist.
Ich empfehle hier die Lektuere von : http://www.hardened-php.net/suhosin/configuration.html
Zumal so mancher "Hoster" der Meinung ist, diese Werte noch zusaetzlich zu beschneiden. Was dann einen in den Wahnsinn treiben kann.
suhosin "kann" sinnvoll sein, wenn man weiss, was man macht.
Generell kann ich persoenlich davon abraten, weil es einfach bei sinnvoller ist, mit anderen Mitteln seine Installation abzusichern.
Und da ist suExec in einer Apache Umgebung einfach mit das sicherste. So wie Andreas_I schon schrieb.
nginx hat dieses Sicherheitsfeature nicht, man kann es aber mit Bordmitteln auch dort machen.
Man muss als Admin halt einfach wissen, was man macht.
Mehr nicht.
Das allein ist sicher kein Qualitätsmerkmal, zumal man über die Gründe, weshalb die 'patches' nicht in PHP integriert werden, dann auch noch durchaus geteilter Meinung sein kann. Mich erinnert die Argumentation Herrn Essers dabei an autistische Hauptentwickler, die der Meinung sind, nur sie allein wüssten was gut und richtig ist.Zitat:
Zitat von Thomas
Suhosin bietet dann auch weder Support für PHP 5.4 und ist deshalb (zu Recht) auch aus diversen Linux-Distributionen herausgeflogen. Zur Arbeitsweise sei noch angemerkt, dass Suhosin letztlich zwei Kernfunktionen bietet: zum einen werden diverse so Variablen konfiguriert, dass man sie für sicher(er) halten kann als die Standardvorgaben, zum anderen werden Routinen etliche Verschlüsselungfunktionen u.a für das Sessionmanagement implementiert. Nichts, was man nicht auch selbst machen könnte.
Alleine die (auch in der Vergangenheit) sehr zögerliche Updatepolitik des Projektes, das einen immer zwischen Pest und Cholera wählen lässt - entweder ein frisches PHP bei dem Bugs gefixt wurden oder ein veraltetes, bei dem Suhosin dann einen draufsetzt um die Sicherheit zu verbessern. Sorry, aber das ist nicht wirklich gut so.
Carolina.
Wenn ich geahnt hätte, dass ich hier gleich einen solchen Sturm auslöse... :rolleyes:
@ Andreas:
Danke! :)Zitat:
In der neuesten Version die bald ins ER kommt werden zumindest rudimentäre Synchronisationen möglich sein, trotz Suhosin. Fopen benötigst du aber weiterhin, sonst könnten die Backups nicht funktionieren. Falls du keine Lust hast aufzurüsten oder es in deinem Fall nicht geht, versuch trotzdem mal eine Synchronisation. Wir sind immer mal wieder dran zu optimieren, manchmal erledigen sich dadurch wichtige PHP-Konfigurationen von selbst.
Ich hab's jetzt probiert, mit fopen, aber ohne an den suhosin-Einstellungen was zu ändern (da ich eh nicht weiß, was):
Schritt 1 läuft, dann läuft Schritt 2 an und dann bekomme ich irgendwann eine weiße Seite.
Im Logfile steht:
Dort wiederum steht dann:Code:[02-Jun-2012 17:24:37] PHP Fatal error: Maximum execution time of 30 seconds exceeded in C:\xampp\...system\libraries\RequestExtended.php on line 931
was mir nicht viel sagt.PHP-Code:$varData = fread($this->socket, 1024);
Kann es mit dieser Anmerkung im Systemcheck zusammenhängen?
Wo muss ich was ändern?Zitat:
Der MaxRequestLen ist zu gering
Das besagt lediglich, dass deine Scripte nach 30 Sekunden vom Server abgebrochen werden.
In der php.ini kannst du diese maximum execution time hochsetzen.
Deine Synchronisation kann dein Server nicht schnell genug durchfyhren (zu grosse Seite oder aber zu lahme Hardware oder beides), weshalb dann der Stecker gezogen wird.
Und Styrme sind doch nichts schlechtes. ;)
Gruss
Chris
Danke!
Der erste zaghafte Synchronisationsversuch scheint zumindest zu funktionieren. ;)