open_basedir und suphp

Till

Administrator
Das sieht soweit ok aus. Dann poste mal:

ls -la /var/www/web10/web/index.php

und schau bitte in das error.log der Webseite, welcher Fehler dort geloggt wird. Stelle bitte auch sicher, dass das Wrapperscript ausführbar ist.
 

xwsnet

New Member
Das sieht soweit ok aus. Dann poste mal:

ls -la /var/www/web10/web/index.php

-rwxrwxr-x 1 web10_1 web10 8491 2007-03-30 16:05 /var/www/web10/web/index.php
x und schau bitte in das error.log der Webseite, welcher Fehler dort geloggt wird. Stelle bitte auch sicher, dass das Wrapperscript ausführbar ist.

Ich habe den Fehler grade noch einmal erzeugt. Im Error.log der Webseite steht nichts und im Error.log vom Apache steht "nur"

[Wed Dec 12 10:36:24 2007] [info] removed PID file /var/run/apache2.pid (pid=23532)
[Wed Dec 12 10:36:24 2007] [notice] caught SIGTERM, shutting down
[Wed Dec 12 10:36:26 2007] [info] Init: Seeding PRNG with 136 bytes of entropy
[Wed Dec 12 10:36:26 2007] [info] Init: Generating temporary RSA private keys (512/1024 bits)
[Wed Dec 12 10:36:26 2007] [info] Init: Generating temporary DH parameters (512/1024 bits)
[Wed Dec 12 10:36:26 2007] [info] Init: Initializing (virtual) servers for SSL
[Wed Dec 12 10:36:26 2007] [info] Server: Apache/2.2.3, Interface: mod_ssl/2.2.3, Library: OpenSSL/0.9.8c
[Wed Dec 12 10:36:26 2007] [notice] suEXEC mechanism enabled (wrapper: /usr/lib/apache2/suexec)
[Wed Dec 12 10:36:26 2007] [info] mod_unique_id: using ip addr 81.95.0.138
[Wed Dec 12 10:36:27 2007] [notice] ModSecurity for Apache 2.1.1 configured
[Wed Dec 12 10:36:27 2007] [info] Init: Seeding PRNG with 136 bytes of entropy
[Wed Dec 12 10:36:27 2007] [info] Init: Generating temporary RSA private keys (512/1024 bits)
[Wed Dec 12 10:36:27 2007] [info] Init: Generating temporary DH parameters (512/1024 bits)
[Wed Dec 12 10:36:27 2007] [info] Init: Initializing (virtual) servers for SSL
[Wed Dec 12 10:36:27 2007] [info] Server: Apache/2.2.3, Interface: mod_ssl/2.2.3, Library: OpenSSL/0.9.8c
[Wed Dec 12 10:36:27 2007] [info] mod_unique_id: using ip addr 81.95.0.138
[Wed Dec 12 10:36:28 2007] [notice] Apache configured -- resuming normal operations
[Wed Dec 12 10:36:28 2007] [info] Server built: Jun 17 2007 20:24:06
[Wed Dec 12 10:36:40 2007] [error] [client 58.65.237.153] File does not exist: /var/www/sharedip/index, referer: XXXXX
[Wed Dec 12 10:37:06 2007] [info] removed PID file /var/run/apache2.pid (pid=16660)
[Wed Dec 12 10:37:06 2007] [notice] caught SIGTERM, shutting down
[Wed Dec 12 10:37:08 2007] [info] Init: Seeding PRNG with 136 bytes of entropy
[Wed Dec 12 10:37:08 2007] [info] Init: Generating temporary RSA private keys (512/1024 bits)
[Wed Dec 12 10:37:09 2007] [info] Init: Generating temporary DH parameters (512/1024 bits)
[Wed Dec 12 10:37:09 2007] [info] Init: Initializing (virtual) servers for SSL
[Wed Dec 12 10:37:09 2007] [info] Server: Apache/2.2.3, Interface: mod_ssl/2.2.3, Library: OpenSSL/0.9.8c
[Wed Dec 12 10:37:09 2007] [notice] suEXEC mechanism enabled (wrapper: /usr/lib/apache2/suexec)
[Wed Dec 12 10:37:09 2007] [info] mod_unique_id: using ip addr 81.95.0.138
[Wed Dec 12 10:37:10 2007] [notice] ModSecurity for Apache 2.1.1 configured
[Wed Dec 12 10:37:10 2007] [info] Init: Seeding PRNG with 136 bytes of entropy
[Wed Dec 12 10:37:10 2007] [info] Init: Generating temporary RSA private keys (512/1024 bits)
[Wed Dec 12 10:37:10 2007] [info] Init: Generating temporary DH parameters (512/1024 bits)
[Wed Dec 12 10:37:10 2007] [info] Init: Initializing (virtual) servers for SSL
[Wed Dec 12 10:37:10 2007] [info] Server: Apache/2.2.3, Interface: mod_ssl/2.2.3, Library: OpenSSL/0.9.8c
[Wed Dec 12 10:37:10 2007] [info] mod_unique_id: using ip addr 81.95.0.138
[Wed Dec 12 10:37:11 2007] [notice] Apache configured -- resuming normal operations
[Wed Dec 12 10:37:11 2007] [info] Server built: Jun 17 2007 20:24:06

Was meinst du mit sicherstellen, dass das Wrapperscript ausführbar ist?
 

Till

Administrator
Das Wrapperscript muss ja durch suphp gestartet werden, dazu benötig es ausführungs Berechtigungen. Die kannst Du mit:

chmod +x namedeswrapperscriptes.sh

setzen
 

sqrt

New Member
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:

#!/bin/sh

BASEDIR=`/usr/bin/dirname ${DOCUMENT_ROOT}`
TMPDIR=${BASEDIR}/phptmp
SESSDIR=${TMPDIR}

if [ X"${php_safe_mode}" != X"On" ]; then
SAFE_MODE="Off"
else
SAFE_MODE="On"
fi

exec /usr/bin/php5-cgi -d open_basedir=${BASEDIR} -d upload_tmp_dir=${TMPDIR} -d session.save_path=${SESSDIR} -d safe_mode=${SAFE_MODE}

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:
if($go_info["server"]["apache2_php"] == 'suphp'){
$php .= "suPHP_Engine on\n";
$php .= "suPHP_UserGroup ".$webadmin." web".$web["doc_id"]."\n";
$php .= "AddHandler x-httpd-php .php .php3 .php4 .php5\n";
$php .= "suPHP_AddHandler x-httpd-php\n";
if ($web["web_php_safe_mode"]) {
$php .= "SetEnv php_safe_mode On\n";
} else {
$php .= "SetEnv php_safe_mode Off\n";
}

}

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! ;)
 

xwsnet

New Member
Das wird ja immer besser...
Da ich den Safe_Mode zwar nicht mehr nutze, seitdem ich SuPHP installiert habe ist mir das noch nicht aufgefallen, aber das ist interessant zu wissen, dass ich die funktion verloren hatte, und sie jetzt wieder habe :)

Danke! Du bist echt klasse
 

sqrt

New Member
:D 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... :p
 

Damian

New Member
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 :rolleyes:

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 :cool:

Gruß an Alle, Dank an die Entwickler 1A Support :)
Damian
 

TauTau

New Member
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?
 

TauTau

New Member
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:

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}
 

Till

Administrator
Ja, deaktiviere die PHP Checkbox in den Website Einstellungen und schreibe ggf. abweichende PHP direktiven zur aktivierung eines CGI PHP oder mod_php in das apache directiven Feld der Webseite.
 

Feanwulf

Member
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
 

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:

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}
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 :confused:
 
Zuletzt bearbeitet:

Till

Administrator
habt Ihr vielleicht eine Ahnung, wo ich den Fehler habe?

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 :confused:

Die User Webs unterstützen ja auch kein Scripting.
 

Werbung

Top