[FYI] PHP safe_mode + register_globals wurde entfernt

[andreask2]

Hallo!

Was vor einigen Monaten beim Entwickler-Meeting in Paris beschlossen wurde, ist diese Woche in die Tat umgesetzt worden: Es wurde damit begonnen den safe_mode und die safe_mode Checks aus der CVS-Version von PHP zu entfernen: http://news.php.net/php.cvs/36918

Dauert zwar noch was bis entsprechend stabile Versionen veröffentlicht werden, allerdings sollte man sich IMHO schonmal Gedanken über Alternativen machen, wenn man mod_php + safe_mode einsetzt.

Hier ist das was Rasmus Lerdorf für shared hosting empfiehlt:

http://marc.theaimsgroup.com/?l=php-dev ... 700938&w=2
http://news.php.net/php.internals/20413


Grüße
Andreas

edit: register_globals http://www.rootforum.org/forum/viewtopi ... 038#250038

[pg-computer]

Hoi,

finde ich persönlich keine gute Entwicklung - wer es abschalten will, kann dies doch tun. :idea:
Naja bleibt wohl nur PHP in Verbindung mit su_php oder halt mit fastcgi - sind ja eigentlich eh die besseren Alternativen.

[isotopp]

finde ich persönlich keine gute Entwicklung - wer es abschalten will, kann dies doch tun. :idea:
Naja bleibt wohl nur PHP in Verbindung mit su_php oder halt mit fastcgi - sind ja eigentlich eh die besseren Alternativen. :wink:

Im Gegensatz safe_mode funktioniert das dann sogar auch.

safe_mode macht ein Sicherheitsversprechen, das nicht gehalten werden kann. Darum wird es entfernt.

[andreask2]

finde ich persönlich keine gute Entwicklung - wer es abschalten will, kann dies doch tun. :idea:

Ich finds gut, weil sich viele Leute mit dem safe_mode in falscher "Sicherheit" wiegen.

http://ilia.ws/archives/18_PHPs_safe_mo ... urity.html
http://de3.php.net/security-note.php

Naja bleibt wohl nur PHP in Verbindung mit su_php oder halt mit fastcgi - sind ja eigentlich eh die besseren Alternativen.

genau! Oder eben die von Rasmus vorgeschlagene Variante mit einer Apache-Instanz pro User. Oder eben lighttpd + mod_fastcgi.

[flo]

Oder eben die von Rasmus vorgeschlagene Variante mit einer Apache-Instanz pro User.

Ich hab mich da jetzt mal eingelesen, hab derzeit auch (... seit langem ...) einen Serverumzug vor mir und das auf dem neuen System realisiert. Mir gefällt an der Lösung über verschiedene Instanzen und den Proxy, daß sämtliche Optionen neu konfigurierbar sind und die Steuerung optimal ist - werde mal sehen, wie sich das im Betrieb auswirkt.

Zeitaufwand war jetzt - mit Kernel/Apache/php/mysql neu backen insgesamt dreieinhalb Stunden, also erträglich.

flo.

[andreask2]

Zeitaufwand war jetzt - mit Kernel/Apache/php/mysql neu backen insgesamt dreieinhalb Stunden, also erträglich.

Und von der Konfiguration her müsste es ja auch vergleichbar sein, an Stelle einer extra vhost Datei kommt dann am besten wohl eine userspezifische "httpd.conf", die bis auf ein paar Kleinigkeiten ebenfalls nur die eintsprechende vhost Konfiguration braucht, die meisten Einstellungen lassen sich sicher per include aus einer zentralen httpd.conf einbinden - oder? Wie machst Du das, so dass man auch bei ein paar mehr Usern/vHosts noch den Überblick behält?

Wie sind Deine Erfahrungen bzgl. Speicherverbrauch/Auslastung gegenüber einem SuPHP/CGI System?

Wie hast Du das mit den start/stop Scripten geregelt?

Übrigens hat "register_globals" inzwischen dasselbe Schicksal wie den "safe_mode" ereilt: http://news.php.net/php.internals/22122
Das heißt, Sachen wie <?php echo $PHP_SELF; ?> funktionieren endgültig nicht mehr... Ich finde diese Entwicklung gut!

[flo]

Wie hast Du das mit den start/stop Scripten geregelt?

Grobentwurf und dirty Hack :-):

Code: Select all

[root@ns3][20:31:52][0.00 0.00][tmp:noexec](~) # cat /root/scripts/restart_http_proxies.sh 
#!/bin/bash

CONFDIR="/usr/local/conf/proxyhosts"
BASEPORT="8080"
LOCALIP="xxx.xxx.xxx.xxx"
VIRTHOSTFILE="/usr/local/apache2/conf/virthosts_proxy.conf"

echo "## Autoconfigure on" > "$VIRTHOSTFILE"
echo -n "## " >> "$VIRTHOSTFILE"
date >> "$VIRTHOSTFILE"

WWWPORT="$BASEPORT"

for i in $CONFDIR/*.conf; do
        WWWPORT=$(($WWWPORT+1))

        WWWUSER=`ls -lisa "$i" | /usr/bin/awk '{ print $5 }'`
        WWWGROUP=`ls -lisa "$i" | /usr/bin/awk '{ print $6 }'`
        WWWALIAS=`grep "^#ServerAlias" $i | head -1 | sed 's/^#//wq'`
        WWWSERVER=`grep "^ServerName" $i | head -1 | sed 's/^ServerName //'`

        if [ ! -z ${WWWUSER} ]; then
                SERVERNAME=`basename "$i" ".conf"`
                echo -n $SERVERNAME": "

                if [ -z "$WWWSERVER" ]; then
                        WWWSERVER="$SERVERNAME"
                fi;

                /usr/local/apache2/bin/httpd -f ${i} 
                        -c "User ${WWWUSER}" 
                        -c "Group ${WWWGROUP}" 
                        -c "PidFile $i.pid" 
                        -c "Listen 127.0.0.1:${WWWPORT}" 
                        -k graceful && echo "... restarted fine!"

                cat << EOF >> "$VIRTHOSTFILE"

#
# BEGIN ${WWWSERVER}
<VirtualHost ${LOCALIP}>
        ServerName ${WWWSERVER}
        ${WWWALIAS}
        ProxyPass / http://127.0.0.1:${WWWPORT}/

        ErrorLog /var/log/webalizer/_err.log
        CustomLog /var/log/webalizer/_acc.log combined

        <Location /webDAV/>
                ForceType text/plain
                AuthType Basic
                AuthName DAV
                AuthUserFile /usr/local/conf/ftp_DAV_users_htaccess 
                require user ${WWWUSER} 
                DavMinTimeout 600
        </Location>

        <Location /server-status>
                AuthType Basic
                AuthName "restricted"
                AuthUserFile /usr/local/conf/ftp_DAV_users_htaccess
                require user ${WWWUSER}
        </Location>
</VirtualHost>
#
# END ${WWWSERVER}
EOF

        fi;
done

apachectl graceful

Es funktioniert soweit ... bin gerade im Streß ... :-(

Probleme bestehen noch insofern, daß bei Änderung des Ports ein graceful kein Einlesen des neuen Ports bewirkt und die Instanz vorher beendet werden muß.

Und ja - die Apache-Config habe ich vorher in etliche Einzeldateien aufgeteilt und benutze die teilweise für Front- und Backend.

flo.

[oxygen]

Also ich finde die Variante mit mehreren Apache Instanzen eher Suboptimal. In Umgebungen mit stark und weniger stark beanspruchten Vhosts ist die Verteilung der Threads/Prozesse zu unflexibel. Ein globales Client Limit ist so schlecht zu realisieren, auf Lastwechsel kann man nur manuell reagieren.
Außerdem kommt noch dazu, dass durch den Proxy die IP des Clients z.B. für Sessionverwaltung und Co. nur noch umständlich bzw. unkonventionell festgestellt werden kann.

Ich denke im Moment ist die Apache Fundation gefordert endlich die Entwicklung des perchild MPM oder eines das einen vergleichbaren Funktionsumfang hat, voran zu treiben. Auch wenn dass dann nicht so performat wie leader oder event ist, würde es sicher besser funktionieren, als für jeden VHost einen extra Apache Prozess laufen zu lassen.

[flo]

Ich denke im Moment die die Apache Fundation gefordert endlich die Entwicklung des perchild MPM oder eines das einen vergleichbaren Funktionsumfang hat, voran zu treiben.

Sicher - vollste Zustimmung, aber:

Ich konnte mich mit so einem sch...komplizierten Setup auch nicht anfreunden, bis ich mir überlegt habe, daß man die Ressourcen natürlich super verteilen kann und natürlich auch verhindern kann, daß ein Kunde sozusagen den Server komplett übernimmt.

Auf perchild warte ich sehnlichst, ich weiß auch nicht, warum die Entwicklung an der Stelle nciht weitergeht.

flo.

[andreask2]

Also ich finde die Variante mit mehreren Apache Instanzen eher Suboptimal. In Umgebungen mit stark und weniger stark beanspruchten Vhosts ist die Verteilung der Threads/Prozesse zu unflexibel. Ein globales Client Limit ist so schlecht zu realisieren, auf Lastwechsel kann man nur manuell reagieren.

Da sich gleiche Prozesse auf den mordernen Linux-Systemen die Resourcen sehr effizient teilen, sehe ich da eigentlich kein großes Problem - im Gegenteil, wie flo schon sagte kann man sogar sehr gut die Resourcen der User begrenzen.
Trotzdem ist es mit ziemlicher Sicherheit immer noch ne Ecke effizienter als CGIs - man kann sogar Opcode Caches einsetzen (wenn man ausreichend RAM hat) und die vorgelagerte Apache/mod_proxy Variante zum Cachen von statischen Inhalten verwenden (oder vielleicht direkt gegen den effizienteren Squid ersetzen?)...

Außerdem kommt noch dazu, dass durch den Proxy die IP des Clients z.B. für Sessionverwaltung und Co. nur noch umständlich bzw. unkonventionell festgestellt werden kann.

Ja, das ist in der Tat ein Problem. Allerdings gibt es nicht so viele Anwendungen die sich sinnvollerweise auf Client-IP Adressen verlassen, höchtens für Dokumentations-Zwecke, gerade für Sessions ist das z.B. wenig sinnvoll.

Ich denke im Moment ist die Apache Fundation gefordert endlich die Entwicklung des perchild MPM oder eines das einen vergleichbaren Funktionsumfang hat, voran zu treiben. Auch wenn dass dann nicht so performat wie leader oder event ist, würde es sicher besser funktionieren, als für jeden VHost einen extra Apache Prozess laufen zu lassen.

Naja, perchild wurde meines Wissens schon vor einiger Zeit eingestellt (in der Apache 2.2 Doku fehlt es auch komplett), vom Metux MPM gibt es auch seit 1 Jahr keinen Release mehr (und das Patch ist für eine 2 Jahre alte Apache-Version). Das ist alles tierisch instabil, hat alle möglichen Beschränkungen (kein SSL, kein KeepAlive...) und ist sicherheitstechnisch wohl auch nicht ganz unproblematisch...
Das Neuste von der Sorte ist wohl das PerUser MPM, das gibt es auch für Apache 2.0.55. Das verwendet keine Threads mehr, hat einen Prozess-Pool für jede UID, also technisch gesehen nicht viel anders als mehrere Apache Instanzen. Vorteile ist natürlich, dass es minimal effizienter sein könnte, da die Request nicht von einem Proxy per HTTP weitergeleitet werden, sondern per IPC. Auf der anderen Seite verwendet die Variante mit den Apache Instanzen ausschließlich sehr ausgereifte Software, das PerUser MPM dagen ist noch lange nicht stabil.

Ich halte PerUser für den sinnvollsten Ansatz, wenn das irgendwann stabil ist und gut durchdacht, wird es vermutlich die effizienteste und praktikabelste Lösung sein. Da es nicht multithreaded ist, hat man auch keine Probleme mit PHP, was Performance und Stabilität unter Last angeht...

Allerdings wundert es mich, dass so wenige Entwickler sich für diese Module interessieren... Aber vermutlich ist das ganze - vor allem bei multithreaded Webservern - auch nicht ganz so einfach zu implementieren wie es sich anhört...

[cyber-shadow]

Ich hänge mich mal hier dran...

Was haltet ihr von itk? Ich habe das gerade auf einem Test-Server installiert (geht zum Glück bei Gentoo sehr einfach per USE-Flag) und bin ganz zufrieden. Läuft stabiler als peruser (da hatte ich in letzter Zeit seit einem Update segfaults, die ich nicht beheben konnte) und man kann die Usernamen direkt in den Vhosts konfigurieren ohne dass man sie vorher "definieren" muss (wie mit der Processor-Direktive bei peruser).

Allerdings habe ich den Eindruck, dass der Apache länger als root läuft als bei peruser? Habe das aber noch nicht so genau untersucht...