open_basedir und suphp
- Ersteller des Themas xwsnet
- Erstellungsdatum
Ich habe den Fehler grade noch einmal erzeugt. Im Error.log der Webseite steht nichts und im Error.log vom Apache steht "nur"
Was meinst du mit sicherstellen, dass das Wrapperscript ausführbar ist?
Erweiterung um safe_mode-Einstellung
Alle, die suPHP mit dem oben beschriebenen Wrapper-Script einsetzen weden schon bemerkt haben, das die Option "PHP Safe Mode" in ISPConfig keine Wirkung mehr hat. Da ich aber nicht auf diese Option, den PHP Safe Mode für einzelen Webs an- und abzuschalten verlieren wollte, habe ich auch hier nach einer praktikablen Lösung gesucht und mein Wrapper-Script wie folgt erweitert:
Im Script wird jetzt eine Umgebungsvariable namens "php_safe_mode" abgefragt. Leider ist diese Variable aber vorerst noch nicht gesetzt. Fügt man aber in das betreffende Web in das Feld für die Apache-Directiven folgende Zeile ein, wird vom Apache die Umgebungsvariable auf on gesetzt, und PHP-Script laufen im "Safe Mode":
Aber auch das war mir noch zu umständlich und auch noch nicht elegant genug, da es ja auch in der GUI immerhin schon einen "Knopf" für diese Einstellung gibt. In der Datei /root/ispconfig/scripts/lib/config.lib.php wurde ich schließlich fündig:
Fett markiert die Zeilen, die ich eingefügt habe. Diese Zeilen bewirken, dass wenn suPHP aktiviert ist, die Direktiven zum Setzen der php_safe_mode-Umgebungsvariable abhängig vom Häkchen im Kontrollfeld korrekt gesetzt wird. Jetzt kann man den PHP-Safe-Mode auch mit suPHP über das Wrapper-Script bequem an- und abschalten.
Viel Spass damit!
Alle, die suPHP mit dem oben beschriebenen Wrapper-Script einsetzen weden schon bemerkt haben, das die Option "PHP Safe Mode" in ISPConfig keine Wirkung mehr hat. Da ich aber nicht auf diese Option, den PHP Safe Mode für einzelen Webs an- und abzuschalten verlieren wollte, habe ich auch hier nach einer praktikablen Lösung gesucht und mein Wrapper-Script wie folgt erweitert:
Im Script wird jetzt eine Umgebungsvariable namens "php_safe_mode" abgefragt. Leider ist diese Variable aber vorerst noch nicht gesetzt. Fügt man aber in das betreffende Web in das Feld für die Apache-Directiven folgende Zeile ein, wird vom Apache die Umgebungsvariable auf on gesetzt, und PHP-Script laufen im "Safe Mode":
Aber auch das war mir noch zu umständlich und auch noch nicht elegant genug, da es ja auch in der GUI immerhin schon einen "Knopf" für diese Einstellung gibt. In der Datei /root/ispconfig/scripts/lib/config.lib.php wurde ich schließlich fündig:
Fett markiert die Zeilen, die ich eingefügt habe. Diese Zeilen bewirken, dass wenn suPHP aktiviert ist, die Direktiven zum Setzen der php_safe_mode-Umgebungsvariable abhängig vom Häkchen im Kontrollfeld korrekt gesetzt wird. Jetzt kann man den PHP-Safe-Mode auch mit suPHP über das Wrapper-Script bequem an- und abschalten.
Viel Spass damit!
Freut mich, wenn ich helfen konnte und wenn noch andere meine Lösung nützlich finden.Durch die Möglichkeit, über die VirtualHost-Directiven eigene Umgebungsvariablen setzen zu können, wird das Wrapper-Script sehr flexibel. So könnte man auch über eine weitere Variable dem Web eine eigene php.ini zuweisen während alle anderen die Standard-php.ini nutzen usw.
Die gesamte PHP-Konfiguration wird dadurch sehr detailliert anpassbar, wenn es mal nötig wird.
Aber, wie weiter oben im Thread schon mal kurz angesprochen. Das Auswerten der Umgebungsvariablen (und auch das Setzen) sollte man sehr, sehr sorgfältig machen. Auch wenn die Gefahr gering ist, das jemand von Außen die Umgebungsvariablen manipulieren könnte... es reicht ein blöder Tippfehler bei einer SetEnv-Direktive, und man schafft sich selber eine Lücke. In meinem Beispiel mit der php_safe_mode-Variablen benutze ich aus genau diesem Grund nicht den Inhalt der Variablen direkt, um sie an den PHP-Aufruf anzuhängen sondern lege dafür extra einen Variable an, die immer mit sinnvollen Werten gefüllt ist. Solche Dinge sollte man unbedingt beachten...
Super Problembewältigung
Vielen Dank für diesen wunderbaren Thread!! (Verfolge das schon gespannt ein paar Tage)
Ich hoffe ja diese Problemlösung wird in die nächste Version als Option mit aufgenommen.
Bereits seit Januar 2007 suche ich eine kompetente Lösung für dieses Verzeichnisproblem. Jedes mal wenn ich mit einer PHP-Securityshell dort rangegangen bin, hat mich der Anblick des www-Ordnerinhaltes fast in den Wahnsinn getrieben - viele eigene Lösungsversuche gestartet, nie komplett erfolgreich.
Mein OS ist Debian Etch und ich hatte schon eine Reihe serverspezifischer Probleme zu lösen was andere Apps angeht.
Erstmal ist es super, dass es seit kurzem ein deutschsprachiges Forum gibt, weil das ewige Lesen auf englisch hat nun auch nicht so wirklich Spaß gebracht, weil ja dort doch einige User deutsch können, wie man anhand der Fehler im englischen Forum bemerken konnte
Seit dem ich ISPConfig kenne, möchte ich es am liebsten heiraten.
Ich werde die Lösung mal auf dem Produktionsserver versuchen und dann demnach Feedback geben
Gruß an Alle, Dank an die Entwickler 1A Support
Damian
Vielen Dank für diesen wunderbaren Thread!! (Verfolge das schon gespannt ein paar Tage
)Ich hoffe ja diese Problemlösung wird in die nächste Version als Option mit aufgenommen.
Bereits seit Januar 2007 suche ich eine kompetente Lösung für dieses Verzeichnisproblem. Jedes mal wenn ich mit einer PHP-Securityshell dort rangegangen bin, hat mich der Anblick des www-Ordnerinhaltes fast in den Wahnsinn getrieben - viele eigene Lösungsversuche gestartet, nie komplett erfolgreich.
Mein OS ist Debian Etch und ich hatte schon eine Reihe serverspezifischer Probleme zu lösen was andere Apps angeht.
Erstmal ist es super, dass es seit kurzem ein deutschsprachiges Forum gibt, weil das ewige Lesen auf englisch hat nun auch nicht so wirklich Spaß gebracht, weil ja dort doch einige User deutsch können, wie man anhand der Fehler im englischen Forum bemerken konnte
Seit dem ich ISPConfig kenne, möchte ich es am liebsten heiraten.
Ich werde die Lösung mal auf dem Produktionsserver versuchen und dann demnach Feedback geben
Gruß an Alle, Dank an die Entwickler 1A Support
Damian
ich habe mal das script versucht anzupassen, um das open_basedir zu erweitern:
if [ X"$(use_pear)" != X"On" ]; then
BASEDIR=$(BASEDIR)
else
BASEDIR=$(BASEDIR):/usr/share/php
fi
allerdings ist dann egal ob ich setEnv user_pear On oder Off setzte, open_basedir gar nicht mehr gesetzt. Was mache ich da falsch?
if [ X"$(use_pear)" != X"On" ]; then
BASEDIR=$(BASEDIR)
else
BASEDIR=$(BASEDIR):/usr/share/php
fi
allerdings ist dann egal ob ich setEnv user_pear On oder Off setzte, open_basedir gar nicht mehr gesetzt. Was mache ich da falsch?
urks, viel einfacher... "{" statt "(" wars dann funzts auch... (aber danke für den Hinweis auf das sinnlose $BASEDIR=$BASEDIR, mit shellscripts kämpf ich immer als perler ) super, endlich kann ich mit der eGroupware Geschichte weitermachen
oh, falls jemand auch diese Möglichkeit braucht, pear einzubinden auf debian, hier das ganze wrapperscript:
dann funzts auch... (aber danke für den Hinweis auf das sinnlose $BASEDIR=$BASEDIR, mit shellscripts kämpf ich immer als perler ) super, endlich kann ich mit der eGroupware Geschichte weitermachen oh, falls jemand auch diese Möglichkeit braucht, pear einzubinden auf debian, hier das ganze wrapperscript:
Code:
#!/bin/sh
PATH="/sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/libexec"
BASEDIR=`dirname ${DOCUMENT_ROOT}`
TMPDIR=${BASEDIR}/phptmp
SESSDIR=${TMPDIR}
if [ X"${php_safe_mode}" != X"On" ]; then
SAFE_MODE="Off"
else
SAFE_MODE="On"
fi
if [ X"${use_pear}" == X"On" ]; then
BASEDIR=${BASEDIR}:/usr/share/php
fi
exec php-cgi -d open_basedir=${BASEDIR} -d upload_tmp_dir=${TMPDIR} -d session.save_path=${SESSDIR} -d safe_mode=${SAFE_MODE}Hat geklappt mit folgenden direktiven:
LoadModule php5_module /usr/lib/apache2/modules/libphp5.so
AddType application/x-httpd-php .php .php3 .php4
php_admin_value session.save_path /var/www/webX/tmp
#php_admin_value doc_root /var/www/webX
#php_admin_value open_basedir .:/var/www/webX
#php_admin_value upload_tmp_dir /var/www/webX/tmp
LoadModule php5_module /usr/lib/apache2/modules/libphp5.so
AddType application/x-httpd-php .php .php3 .php4
php_admin_value session.save_path /var/www/webX/tmp
#php_admin_value doc_root /var/www/webX
#php_admin_value open_basedir .:/var/www/webX
#php_admin_value upload_tmp_dir /var/www/webX/tmp
celocore
Member
Hallo auch,
dieser Thread ist zwar schon älter, hat mich aber in Verbindung mit http://www.howtoforge.com/install-s...tions-for-use-with-ispconfig-2.2.20-and-above auf den, denke ich mal, richtigen Weg gebracht. suPHP funktioniert.
Ich möchte jetzt in /var/www/typo3 zentral die TYPO3-Source halten und aus den webs darauf verlinken. Dazu habe ich unter /home/admispconfig/ispconfig/tools/suphp/usr/bin/ das wrapperscript wie folgt angepaßt:
Mit phpinfo() sehe ich auch, dass open_basedir entprechend gesetzt ist. Allerdings wird mein Zugriff auf www.domain.tld/typo3/install/index.php (was ja in den verlinkten Source geht) mit der Meldung
[Thu Jun 11 15:06:37 2009] [warn] File "/var/www/typo3/typo3_src-4.2.6/typo3/install/index.php" is not in document root of Vhost "/var/www/web1/web"
belohnt.
habt Ihr vielleicht eine Ahnung, wo ich den Fehler habe?
Was mir in diesem Zusammenhang noch aufgefallen ist... php-Skripte aus dem web-root klappen, aber bei php-Skripten aus dem web eines Benutzers (www.domain.tld/~webnutzer) bieten die Browser nur zum Download an
dieser Thread ist zwar schon älter, hat mich aber in Verbindung mit http://www.howtoforge.com/install-s...tions-for-use-with-ispconfig-2.2.20-and-above auf den, denke ich mal, richtigen Weg gebracht. suPHP funktioniert.
Ich möchte jetzt in /var/www/typo3 zentral die TYPO3-Source halten und aus den webs darauf verlinken. Dazu habe ich unter /home/admispconfig/ispconfig/tools/suphp/usr/bin/ das wrapperscript wie folgt angepaßt:
Code:
#!/bin/sh
PATH="/sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/libexec"
BASEDIR=`dirname ${DOCUMENT_ROOT}`
TMPDIR=${BASEDIR}/phptmp
SESSDIR=${TMPDIR}
if [ X"${php_safe_mode}" != X"On" ]; then
SAFE_MODE="Off"
else
SAFE_MODE="On"
fi
BASEDIR=${BASEDIR}":/var/www/typo3"
exec php-cgi -d open_basedir=${BASEDIR} -d upload_tmp_dir=${TMPDIR} -d session.save_path=${SESSDIR} -d safe_mode=${SAFE_MODE}[Thu Jun 11 15:06:37 2009] [warn] File "/var/www/typo3/typo3_src-4.2.6/typo3/install/index.php" is not in document root of Vhost "/var/www/web1/web"
belohnt.
habt Ihr vielleicht eine Ahnung, wo ich den Fehler habe?
Was mir in diesem Zusammenhang noch aufgefallen ist... php-Skripte aus dem web-root klappen, aber bei php-Skripten aus dem web eines Benutzers (www.domain.tld/~webnutzer) bieten die Browser nur zum Download an
Zuletzt bearbeitet:
Scahu doch mal in der suphp.conf datei nach, ob suphp überhaupt dateien die außerhalb des homdirs eines Benutzers liegen ausführen darf. Außerdem wirst Du noch Probleme mit den Rechten bekommen, da bei suphp die Dateien dem admin des Webs gehören müssen. So ein Setup wie Du es machen möchtest ist nicht empfehlenswert.
Was mir in diesem Zusammenhang noch aufgefallen ist... php-Skripte aus dem web-root klappen, aber bei php-Skripten aus dem web eines Benutzers (www.domain.tld/~webnutzer) bieten die Browser nur zum Download an
Die User Webs unterstützen ja auch kein Scripting.
celocore
Member
Hmm, danke Till. Sowas dachte ich mir schon fast... womit ich dann wieder bei meinem anderem Problem wäre (http://www.howtoforge.de/forum/showthread.php?t=1656). Wie löse ich die Problematik mit den Rechten zwischen Webserver- und FTP-Server-Rechten
Bisher lasse ich die mittels Skript automatisch setzen, allerdings ist das etwas unbefriedigend... hmm
Bisher lasse ich die mittels Skript automatisch setzen, allerdings ist das etwas unbefriedigend... hmm