Wie stellt man einen Feature Request?

[Tom]

Hello,

die Sache mit "open_basedir" und "upload_tmp_dir", sowie "session.save_path" beschäftigt mich leider immer noch, da ich nun fleißig Löcher stopfen muss in diversen Installationen von shared Hosts.

Es gibt auch durchaus unterschiedliche Meinungen unter den Hosterfreunden. Die meisten waren allerdings eher "unangenehm irritiert", wenn nicht sogar stinksauer, dass es Verzeichnisse gibt, die nicht durch die open_basedir-Direktive kontrolliert werden.

Das brachte mich auf die Idee, dass man die Verhaltensweise doch von einem kleinen Schalter (oder auch zweien) abhängig machen könnte. "session.save_path__respects_open_basedir" usw. oder so ähnlich.

Diesen Feature-Request würde ich nun gerne bei den PHP-Entwicklern einbringen. Leider weiß ich nicht, wie man das so geschickt formuliert, dass sie es nicht gleich in die Ablage P verschieben.

Wer kann mir da helfen.

Übrigens:
auch wenn das "immer schon so gewesen ist, wie es jetzt ist" halte ich das Feature für überaus sinnvoll und meine diversen Hosterfreunde auch. Die waren bisher schließlich auch der Meinung, dass die Verzeichniszugriffe per open_basedir als Präfix kontrolliert würden. Ich habe das also nicht nur geträumt, auch wenn heute in den vermeintlich alten Unterlagen steht, dass es nicht so war...

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[ChrisB]

Hi,

Das brachte mich auf die Idee, dass man die Verhaltensweise doch von einem kleinen Schalter (oder auch zweien) abhängig machen könnte. "session.save_path__respects_open_basedir" usw. oder so ähnlich.

Hurra, noch ’ne sinnlose Konfigurations-Option mehr.

Diesen Feature-Request würde ich nun gerne bei den PHP-Entwicklern einbringen. Leider weiß ich nicht, wie man das so geschickt formuliert, dass sie es nicht gleich in die Ablage P verschieben.

Wenn du den Vorschlag eingereicht hast, gib’ mit bitte den URL, damit ich dagegen votieren kann.

auch wenn das "immer schon so gewesen ist, wie es jetzt ist" halte ich das Feature für überaus sinnvoll und meine diversen Hosterfreunde auch.

Dann sollten deine Hosterfreunde sich mal Gedanken machen, wie man eine PHP-Multiuser-Umgebung so aufsetzt, dass man solche Krücken wie open_basedir gar nicht erst braucht, um ein „sicheres“ System zu gewährleisten.

MfG ChrisB

[Tom]

Hello,

Dann sollten deine Hosterfreunde sich mal Gedanken machen, wie man eine PHP-Multiuser-Umgebung so aufsetzt, dass man solche Krücken wie open_basedir gar nicht erst braucht, um ein „sicheres“ System zu gewährleisten.

Genau auf diese platte Antwort habe ich gewartet. Die bringt mich mindestest -3 Schritte weiter :-O

Was dir sinnlos erscheint, kann für viele Andere trotzdem enorm sinnvoll sein. Nur weil es eine ungenügende andere Möglichkeite mit dem PHP-Apache-Modul oder eine sehr viel aufwändigere CGI/Fast-CGI möglichkeit gibt, muss man nicht die einfache und in den alten Installationen merkwürdigerweise auch funktionierende Möglichkeit über open_basedir nicht wegwerfen.

Das waren alles Debian-Installatioen. Kann ja sein, dass die das für ihre PHP-Pakete geändert hatten. Jedenfalls waren die Kollegen glücklich damit und hatten auch nie Ärger. Ich versuche mal, das anhand meiner Altinstallationen nachzurecherchieren.

BTW:
Ich finde Deinen unqualifizierten Polterton nun langsam wirklich upgradebedürftig. Man kann den Dialag nämlich inzwischen auch substantiierter und höflicher betreiben. Vielleicht solltest Du dein OS mal auf den neusten Stand bringen?

Vielleicht solltest Du Dir auch über die Begriffe "Mitwrikung" und "Destruktion" erstmal Gedanken machen, bevor Du immer wieder Antworten gibst, die genau genommen am Thema vorbei sind und zudem, vollkommen unqualifiziert. Du "vergisst" benen deiner plumpen Anmache nämlich jedes Mal zu beschreiben, _wie_  es denn anders besser geht.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[ChrisB]

Hi,

dass du es nicht abkannst, wenn man von dir ers(p)onnene Ideen, an denen deiner Meinung nach die PHP-Welt genesen sollte, kritisiert, ist ja nun nichts neues.

Ich halte es aber für kontraproduktiv, die PHP-Entwickler mit so einem Nonsense zu belästigen – die haben mit PHP 6 nun gerade wirklich genug um die Ohren, da musst du nicht auch noch mit solchen Hirnfürzen reinfunken.

MfG ChrisB

[Tom]

Hello,

dass du es nicht abkannst, wenn man von dir ers(p)onnene Ideen, an denen deiner Meinung nach die PHP-Welt genesen sollte, kritisiert, ist ja nun nichts neues.

Ich halte es aber für kontraproduktiv, die PHP-Entwickler mit so einem Nonsense zu belästigen – die haben mit PHP 6 nun gerade wirklich genug um die Ohren, da musst du nicht auch noch mit solchen Hirnfürzen reinfunken.

Schade, immer noch polemisch und unqualifiziert!

Erläutere doch stattdessen mal die Vorgehensweise, die Du für PHP-Apache-Modul-System Verwender, die mehrere Kunden auf einem Host verwalten wollen, parat hast, damit deren Kunden selber Uploads machen können, aber nicht die Kontrolle über das System erhalten können.

Das würde ich für produktiv halten.

Du bist bisher leider nur destruktiv!

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Tach!

Erläutere doch stattdessen mal die Vorgehensweise, die Du für PHP-Apache-Modul-System Verwender, die mehrere Kunden auf einem Host verwalten wollen, parat hast, damit deren Kunden selber Uploads machen können, aber nicht die Kontrolle über das System erhalten können.

Welcher technische Zwang besteht denn, beim Apache-Modul zu bleiben?

dedlfix.

[Tom]

Hello,

Tach!

Erläutere doch stattdessen mal die Vorgehensweise, die Du für PHP-Apache-Modul-System Verwender, die mehrere Kunden auf einem Host verwalten wollen, parat hast, damit deren Kunden selber Uploads machen können, aber nicht die Kontrolle über das System erhalten können.

Welcher technische Zwang besteht denn, beim Apache-Modul zu bleiben?

Es ist schnell, es benötigt am wenigsten Speicher pro Account, der Account (Virtual Host) ist schnell eingerichtet, auch ohne die ganzen Hilfsmittel, wie Plesk, Paralleles, CPanel, usw.

Welche Möglichkeiten siehst Du denn sonst?

Auch DU bist herzlich aufgefordert, substantiiert darzulegen, wie es anders besser geht und warum man die (einst) vernünftige Lösung für kleine Anbieter (zukünftig) fallen lassen sollte.

Auch Du hast noch nichts zur eigentlichen Frage gesagt.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[ChrisB]

Hi,

Auch DU bist herzlich aufgefordert, substantiiert darzulegen, wie es anders besser geht

Wer keine vernünftige™ Shared Hosting Umgebung aufsetzen will, soll halt die genannten Verzeichnisse mit php_admin_value vorgeben. Dann können sie nicht mehr vom Nutzer geändert werden.
Jetzt wirst du argumentieren, dass das auch wieder blöd wäre, weil der Nutzer damit der Chance beraubt würde, für unterschiedliche Scripte unterschiedliche Session-/Uploadverzeichnisse anzugeben. Tja, keine Arme, keine Kekse. Muss man sich halt von solchen Wald-und-Wiesen-Hostern fernhalten, wenn man eine vernünftige Umgebung haben will.

und warum man die (einst) vernünftige Lösung für kleine Anbieter (zukünftig) fallen lassen sollte.

Vielleicht sollte man als Nutzer einfach die „kleinen Anbieter“ fallen lassen, die meinen mit ihrer „ich nutze privat Ubuntu, also kann ich Linux“-Mentalität in den Hostingmarkt einsteigen zu müssen …

MfG ChrisB

[Der Martin]

Hallo,

Vielleicht sollte man als Nutzer einfach die „kleinen Anbieter“ fallen lassen, die meinen mit ihrer „ich nutze privat Ubuntu, also kann ich Linux“-Mentalität in den Hostingmarkt einsteigen zu müssen …

vielleicht aber auch die großen, die nach dem Motto "Nimm, was ich dir anbiete, oder lass es" verfahren, und für individuelle Wünsche grundsätzlich taub sind.

Viel bleibt dazwischen allerdings nicht mehr übrig.

Ciao,
 Martin

[dedlfix]

Tach!

Welcher technische Zwang besteht denn, beim Apache-Modul zu bleiben?
Es ist schnell, es benötigt am wenigsten Speicher pro Account, der Account (Virtual Host) ist schnell eingerichtet, auch ohne die ganzen Hilfsmittel, wie Plesk, Paralleles, CPanel, usw.

Das sind Argumente, die eher in Richtung Geiz (zu wenig Power auf der Maschine) oder Ausrede aber nicht in Richtung technische Notwendigkeit gehen.

SuexecUserGroup ist genau eine Direktive, die mehr zu setzen ist. Die Einrichtung des Verzeichnisses wird der Hoster wohl auch nicht zu Fuß erledigen, so dass er in sein Verwaltungsscript noch die zwei Zeilen für das Anlegen eines Users und ein chown für dessen VHost-Verzeichnisse hinzufügen muss.

Wenn ich mir eine Munin-Speicherauslastungsgrafik für FCGI-PHPs anschaue, so ist die apps-Kurve ziemlich konstant. Wenn hingegen ein Projekt als Apache-Modul angelegt wird, sehe ich einen irreguläreren Verlauf und deutlich höheren Verbrauch.

Welche Möglichkeiten siehst Du denn sonst?

Die Antwort kennst du bereits. FCGI und suExec.

Auch DU bist herzlich aufgefordert, substantiiert darzulegen, wie es anders besser geht und warum man die (einst) vernünftige Lösung für kleine Anbieter (zukünftig) fallen lassen sollte.

Wegen der angestrebten Sicherheit und der stärkeren Maschinen heutzutage?

dedlfix.