Kommentare zu: PHP 4.4.6, 4.4.7, 4.4.8, … http://www.rackblogger.de/2007/03/02/php-446-447-448/ We love to HOST you. :-) Fri, 18 May 2012 04:45:04 +0000 http://wordpress.org/?v=2.0.9 Von: Jürgen Jaritsch http://www.rackblogger.de/2007/03/02/php-446-447-448/#comment-1756 Sun, 04 Mar 2007 12:05:25 +0000 http://www.rackblogger.de/2007/03/02/php-446-447-448/#comment-1756 Viel mehr als "FULL ACK" lässt sich da nicht mehr sagen ;). Viel mehr als “FULL ACK” lässt sich da nicht mehr sagen ;) .

]]> Von: Klaus Keppler http://www.rackblogger.de/2007/03/02/php-446-447-448/#comment-1753 Sun, 04 Mar 2007 10:27:26 +0000 http://www.rackblogger.de/2007/03/02/php-446-447-448/#comment-1753 Klingt doch auch nach einem durchdachten Setup. :-) Ich hatte mod_suid nur mal kurz angeschaut, im Vergleich zu unserer Eigenentwicklung sah ich aber nicht wirklich einen Vorteil darin (im Gegenteil... bei uns kann ich auch noch pro vhost die Systemressourcen (Filehandles, CPU-Time, Speicher, ...) festlegen). Fazit ist doch aber, daß es (auf welche Art auch immer) auf eine gut überlegte Lösung ankommt, bei der User-Scripte immer unter der ID des tatsächlichen Betriebssystem-Nutzers ausgeführt werden. :-) Klingt doch auch nach einem durchdachten Setup. :-)

Ich hatte mod_suid nur mal kurz angeschaut, im Vergleich zu unserer Eigenentwicklung sah ich aber nicht wirklich einen Vorteil darin (im Gegenteil… bei uns kann ich auch noch pro vhost die Systemressourcen (Filehandles, CPU-Time, Speicher, …) festlegen).

Fazit ist doch aber, daß es (auf welche Art auch immer) auf eine gut überlegte Lösung ankommt, bei der User-Scripte immer unter der ID des tatsächlichen Betriebssystem-Nutzers ausgeführt werden. :-)

]]> Von: Jürgen Jaritsch http://www.rackblogger.de/2007/03/02/php-446-447-448/#comment-1742 Sat, 03 Mar 2007 20:41:06 +0000 http://www.rackblogger.de/2007/03/02/php-446-447-448/#comment-1742 >> http://www.heise.de/newsticker/meldung/71862 Die von dir erwähnten Lücken sind nicht von der Hand zuweisen - mit einem vernünftigen Setup jedoch keine Gefährdung. >> Das Problem ist ja, daß bei mod_php User-Code unter den Rechten des Webservers ausgeführt wird. mod_suid >> Wenn man beispielsweise nicht komplett exec() verbieten will, ist spätestens hier auf jedem zweiten Linux-System über noch ganz andere Fehler (libc, Kernel, …) ein Einstieg möglich. Reißleine jail/chroot/vm >> Wenn PHP als CGI unter den jeweiligen Userrechten läuft, kann ich die User schon auf Betriebssystemebene (über Datei-/Verzeichnisrechte) schön sauber voneinander trennen und brauche nie Angst vor dem nächsten safe_mode/…-Bug haben. Darüber mach ich mir auch wenig Gedanken - alles eine Frage der Recht, wie du bereits geschrieben hast. >> Beispielsweise könnte kein Kunde mit SSH-Zugriff in irgendwelche anderen Verzeichnisse gucken, auch ohne für jeden eine einzelne chroot-Jail bereitzustellen. Auch wenn ich kein SSH bei uttx.net anbiete: jeder User ist in seinem dir eingesperrt. >> Ach ja… nicht zuletzt braucht es in diesem Setup nie wieder irgendwelche “world writable”-Dateien oder Verzeichnisse; Mode 0700/0600 reicht für alle Fälle Darüber macht man sich bei keinen vernünftigem Setup Gedanken (sofern nicht unbedingt CGI/Perl im Einsatz ist). Bei meinem FTP-Setup ist FTP-UId = UserId = PHP-UId. Ergo: Geschichten wie 0777 und Co sind für die Tonne *hust* ;). >> http://www.heise.de/newsticker/meldung/71862

Die von dir erwähnten Lücken sind nicht von der Hand zuweisen - mit einem vernünftigen Setup jedoch keine Gefährdung.

>> Das Problem ist ja, daß bei mod_php User-Code unter den Rechten des Webservers ausgeführt wird.

mod_suid

>> Wenn man beispielsweise nicht komplett exec() verbieten will, ist spätestens hier auf jedem zweiten Linux-System über noch ganz andere Fehler (libc, Kernel, …) ein Einstieg möglich.

Reißleine jail/chroot/vm

>> Wenn PHP als CGI unter den jeweiligen Userrechten läuft, kann ich die User schon auf Betriebssystemebene (über Datei-/Verzeichnisrechte) schön sauber voneinander trennen und brauche nie Angst vor dem nächsten safe_mode/…-Bug haben.

Darüber mach ich mir auch wenig Gedanken - alles eine Frage der Recht, wie du bereits geschrieben hast.

>> Beispielsweise könnte kein Kunde mit SSH-Zugriff in irgendwelche anderen Verzeichnisse gucken, auch ohne für jeden eine einzelne chroot-Jail bereitzustellen.

Auch wenn ich kein SSH bei uttx.net anbiete: jeder User ist in seinem dir eingesperrt.

>> Ach ja… nicht zuletzt braucht es in diesem Setup nie wieder irgendwelche “world writable”-Dateien oder Verzeichnisse; Mode 0700/0600 reicht für alle Fälle

Darüber macht man sich bei keinen vernünftigem Setup Gedanken (sofern nicht unbedingt CGI/Perl im Einsatz ist). Bei meinem FTP-Setup ist FTP-UId = UserId = PHP-UId. Ergo: Geschichten wie 0777 und Co sind für die Tonne *hust* ;) .

]]> Von: Klaus Keppler http://www.rackblogger.de/2007/03/02/php-446-447-448/#comment-1739 Sat, 03 Mar 2007 17:54:59 +0000 http://www.rackblogger.de/2007/03/02/php-446-447-448/#comment-1739 Ach ja... nicht zuletzt braucht es in diesem Setup nie wieder irgendwelche "world writable"-Dateien oder Verzeichnisse; Mode 0700/0600 reicht für alle Fälle :) Ach ja… nicht zuletzt braucht es in diesem Setup nie wieder irgendwelche “world writable”-Dateien oder Verzeichnisse; Mode 0700/0600 reicht für alle Fälle :)

]]> Von: Klaus Keppler http://www.rackblogger.de/2007/03/02/php-446-447-448/#comment-1738 Sat, 03 Mar 2007 17:52:40 +0000 http://www.rackblogger.de/2007/03/02/php-446-447-448/#comment-1738 Es gab in der Vergangenheit immer wieder gravierende Lücken, meist im Zusammenhang mit safe_mode/open_basedir usw. In meinen Bookmarks hatte ich spontan noch diese Meldung von Heise: http://www.heise.de/newsticker/meldung/71862 - 'ne kleine Suche mit Google dürfte da sicher noch mehr bringen. Das Problem ist ja, daß bei mod_php User-Code unter den Rechten des Webservers ausgeführt wird. Wenn man beispielsweise nicht komplett exec() verbieten will, ist spätestens hier auf jedem zweiten Linux-System über noch ganz andere Fehler (libc, Kernel, ...) ein Einstieg möglich. Wenn PHP als CGI unter den jeweiligen Userrechten läuft, kann ich die User schon auf Betriebssystemebene (über Datei-/Verzeichnisrechte) schön sauber voneinander trennen und brauche nie Angst vor dem nächsten safe_mode/...-Bug haben. Beispielsweise könnte kein Kunde mit SSH-Zugriff in irgendwelche anderen Verzeichnisse gucken, auch ohne für jeden eine einzelne chroot-Jail bereitzustellen. Es gab in der Vergangenheit immer wieder gravierende Lücken, meist im Zusammenhang mit safe_mode/open_basedir usw. In meinen Bookmarks hatte ich spontan noch diese Meldung von Heise: http://www.heise.de/newsticker/meldung/71862 - ‘ne kleine Suche mit Google dürfte da sicher noch mehr bringen.

Das Problem ist ja, daß bei mod_php User-Code unter den Rechten des Webservers ausgeführt wird. Wenn man beispielsweise nicht komplett exec() verbieten will, ist spätestens hier auf jedem zweiten Linux-System über noch ganz andere Fehler (libc, Kernel, …) ein Einstieg möglich.

Wenn PHP als CGI unter den jeweiligen Userrechten läuft, kann ich die User schon auf Betriebssystemebene (über Datei-/Verzeichnisrechte) schön sauber voneinander trennen und brauche nie Angst vor dem nächsten safe_mode/…-Bug haben. Beispielsweise könnte kein Kunde mit SSH-Zugriff in irgendwelche anderen Verzeichnisse gucken, auch ohne für jeden eine einzelne chroot-Jail bereitzustellen.

]]> Von: Jürgen Jaritsch http://www.rackblogger.de/2007/03/02/php-446-447-448/#comment-1733 Sat, 03 Mar 2007 11:58:30 +0000 http://www.rackblogger.de/2007/03/02/php-446-447-448/#comment-1733 "(primär aus Sicherheitsgründen)" Irgendein konkretes Beispiel? “(primär aus Sicherheitsgründen)”

Irgendein konkretes Beispiel?

]]> Von: Klaus Keppler http://www.rackblogger.de/2007/03/02/php-446-447-448/#comment-1731 Sat, 03 Mar 2007 10:36:50 +0000 http://www.rackblogger.de/2007/03/02/php-446-447-448/#comment-1731 Bei uns ist das eher eine Nebenwirkung, weil ich bewusst nicht mod_php einsetze (primär aus Sicherheitsgründen). Für anspruchsvolle Kunden kommt mod_fastcgi mit PHP (CGI) zum Einsatz. Durch das ganze Caching im Server merkt man bei den meisten Sites ohnehin keinen Unterschied zwischen mod_php und CGI-PHP. Bei uns ist das eher eine Nebenwirkung, weil ich bewusst nicht mod_php einsetze (primär aus Sicherheitsgründen). Für anspruchsvolle Kunden kommt mod_fastcgi mit PHP (CGI) zum Einsatz. Durch das ganze Caching im Server merkt man bei den meisten Sites ohnehin keinen Unterschied zwischen mod_php und CGI-PHP.

]]> Von: Jürgen Jaritsch http://www.rackblogger.de/2007/03/02/php-446-447-448/#comment-1727 Fri, 02 Mar 2007 23:40:44 +0000 http://www.rackblogger.de/2007/03/02/php-446-447-448/#comment-1727 Korrekt. Simultanen Betrieb beider Versionen unter einem User-/Kunden-Host halte ich für wenig sinnvoll (für Tests mag das brauchbar sein, ja). Grundsätzlich muss sich der User entscheiden, welche Version er will - dafür setze ich auf mod_php. Korrekt. Simultanen Betrieb beider Versionen unter einem User-/Kunden-Host halte ich für wenig sinnvoll (für Tests mag das brauchbar sein, ja). Grundsätzlich muss sich der User entscheiden, welche Version er will - dafür setze ich auf mod_php.

]]> Von: Klaus Keppler http://www.rackblogger.de/2007/03/02/php-446-447-448/#comment-1726 Fri, 02 Mar 2007 21:59:32 +0000 http://www.rackblogger.de/2007/03/02/php-446-447-448/#comment-1726 Bei uns kann man übrigens PHP4 und PHP5 parallel nutzen; bei Dir sieht das so aus als ob man das über's Webadmin auswählen muss...? Bei uns kann man übrigens PHP4 und PHP5 parallel nutzen; bei Dir sieht das so aus als ob man das über’s Webadmin auswählen muss…?

]]> Von: Jürgen Jaritsch http://www.rackblogger.de/2007/03/02/php-446-447-448/#comment-1722 Fri, 02 Mar 2007 19:28:34 +0000 http://www.rackblogger.de/2007/03/02/php-446-447-448/#comment-1722 "Bei uns kann jeder Kunde diese Einstellungen individuell setzen" Jup, bei mir auch. Sieht im Webadmin so aus: http://files.uttx.net/stuff_download/phpsettings.png “Bei uns kann jeder Kunde diese Einstellungen individuell setzen”

Jup, bei mir auch. Sieht im Webadmin so aus: http://files.uttx.net/stuff_download/phpsettings.png

]]>