# open_basedir und suphp



## xwsnet (14. Nov. 2007)

Hallo,
ich habe vor einiger Zeit suPHP auf meinem ISPConfig Server installiert. Jetzt ist einem aus meinem Team aufgefallen, dass man mit einem php Script die Config Files und andere Dateien aus anderen Webordnern auslesen kann.
Das wird ja sonst mit dem Safe Mode verhindert.

Ist es möglich "automatisiert" für alle User open_basedir einzustellen auf den entsprechenden WebXX Ordner?

Oder muss ich dafür für jeden User eine eigene php.ini erstellen?

mfg


----------



## Till (14. Nov. 2007)

> Ist es möglich "automatisiert" für alle User open_basedir einzustellen auf den entsprechenden WebXX Ordner?  Oder muss ich dafür für jeden User eine eigene php.ini erstellen?


Das geht leider nur über eine individuelle PHP-Ini, da man bei der Verwendung von SuPHP keine Werte für open_basedir per php_admin value setzen kann.


----------



## planet_fox (15. Nov. 2007)

Ja aber man könnte doch ISPConfig so konfigurieren das er nen Ordner anlegt 
mit sagen wir mal PHP darin einmal PHP5.ini und PHP4.ini erstellt. Dann kann man für die alle Standard einstellen.Für speziele sachen wie regiosters global etc muss man selbst hand anlegen


----------



## Till (15. Nov. 2007)

Zitat von planet_fox:


> Ja aber man könnte doch ISPConfig so konfigurieren das er nen Ordner anlegt
> mit sagen wir mal PHP darin einmal PHP5.ini und PHP4.ini erstellt. Dann kann man für die alle Standard einstellen.Für speziele sachen wie regiosters global etc muss man selbst hand anlegen


Ja, das ist sicherlich eine gute Sache. Ich habe auf einem meiner Server auch ein SuPHP Setup mit angepasster php.ini und hab mich schon über das manualle anlegen geärgert. Ich werde das mal in den Bugtracker als Feature request mit aufnehmen.


----------



## planet_fox (15. Nov. 2007)

Schön das wir den selben gedanken gang haben, das Feature kann man dann auch übern nen optionsbutton ein und auschalten, aber das wern dann eh eine sache für ISP3. Wenn ISP3 raus ist wird dann an der 2er Genaration nichts ausser Sicherheitslücken behoben oder ?


----------



## xwsnet (15. Nov. 2007)

Ich hatte mir das schon so überlegt, einen Ordner zu erstellen in sagen wir /root/ispconfig/phpini/, der dann die php.ini´s beherbergt. Jede individuelle php.ini heißt dann webID_php.ini.
Dann hat man die alle zusammen, da ich auch nicht möchte, dass meine Kunden auf die php.ini direkt zugreifen können.

Jetzt muss ich das nur wahrscheinlich manuell für die 300-400 Kunden anlegen. Schade... Ich hatte gehofft es gäbe schon jemanden, der dafür eine automatisierung erstellt hat.

mfg

p.s. wir es denn ein Update von ISPC2 auf ISPC3 geben? Oder sind die untereinander incompatibel?


----------



## Till (15. Nov. 2007)

> p.s. wir es denn ein Update von ISPC2 auf ISPC3 geben? Oder sind die untereinander incompatibel?


Ein direktes Update wird es nicht geben, da beide unterschiedliche Systemvoraussetzungen haben. Es soll aber eine Importfunktion geben, die ISPConfig 2 Installationen in ein ISPConfig 3 System importiert.


----------



## sqrt (3. Dez. 2007)

Hallo!

Ich häng' mich einfach mal an diesen Thread hier dran.

Seit ein paar Tagen teste ich ISPconfig auf einem Debian Etch-System und bin soweit schon sehr zufrieden damit. Ein Lob an dieser Stelle an die Entwickler!

Nach diesem HowTo habe ich suPHP mit ISPConfig zum Laufen gebracht und bin dabei auch über die 'open_basedir'-Problematik gestolpert. Mein Lösungsansatz dafür sieht so aus:

Ich habe ein Script als Wrapper erstellt:

/usr/local/bin/php5-wrapper:


> #!/bin/sh
> /usr/bin/php5-cgi -d open_basedir=$DOCUMENT_ROOT


Und in der Datei /etc/suphp.conf dann folgenden Eintrag geändert:


> ;Handler for php-scripts
> ;x-httpd-php=php:/usr/bin/php5-cgi
> x-httpd-php=php:/usr/local/bin/php5-wrapper


Ein Aufruf von phpinfo() in verschiedenen Webs zeigt, das die Einstellung von 'open_basedir ' übernommen wurde. Auch ein paar Testscripts, um auf Dateien außerhalb zuzugreifen bleiben an der Einstellung hängen. Soweit scheint auf dem Testsystem alles zu klappen. Von den Experten hier irgendwelche Einwände oder Anmerkungen? Ich erspare mir so die php.ini für jeden User. Das Wrapper-Script kann man natürlich noch etwas weiter anpassen, wenn man noch mehr machen möchte.

Aber wie gesagt, ich kenne ISPConfig erst seit ein paar Tagen und experimentiere noch damit rum...


Gruß,
Andreas


----------



## xwsnet (3. Dez. 2007)

Geile Idee... 
Ich warte jetzt nochmal ne runde, bis einer der Entwickler was dazu gesagt hat und werde dann das mal ausprobieren. Denn für alle Webs die php.ini zu erstellen ist doch sehr mühsam...


----------



## sqrt (3. Dez. 2007)

Wie gesagt... auf meinem Testsystem läuft es soweit ohne Probleme. Obiges Beispiel-Wrapper-Script ist extra mal ganz simpel gehalten. Bei Übergabe der kompletten DOCUMENT_ROOT-Variablen wird dann open_basedir auf z.B. den Wert '_/var/www/webX/web_' gesetzt. Das ist wahrscheinlich vielen zu restriktiv. Folgendes Wrapper-Script erlaubt auch Zugriffe nach '_/var/www/webX_':

/usr/local/bin/php5-wrapper:


> #!/bin/sh
> BASEDIR=`/usr/bin/dirname ${DOCUMENT_ROOT}`
> /usr/bin/php5-cgi -d open_basedir=$BASEDIR


Ist vielleicht etwas angenehmer, da man so z.B. Konfigurationsdateien etc. außerhalb des _DocumentRoot_ ablegen kann, auf die man aber mit PHP noch zugreifen kann. Ist aber Geschmackssache bzw. eine Frage der eingesetzten Software.

Würde mich freuen, wenn mein Lösungsvorschlag irgendwie bei der Problematik hilft. Dann muss ich nicht weiter suchen... 

Schön ist natürlich, dass man dem _php5-cgi_-Binary über den Parameter '_-d_' noch viele andere Konfigurationsoptionen übergeben kann.

-- 
Gruß,
Andreas


----------



## Till (4. Dez. 2007)

Interessanter Ansatz! Ich denke, es sollte gut funktionieren.


----------



## sqrt (4. Dez. 2007)

Ich sehe auch noch kein wirkliches Problem bei der Vorgehensweise. Auf meinem Testsystem gibt es keinerlei Auffälligkeiten. Anfang nächsten Jahres werd' ich dann aber wohl auch den Produktiv-Test machen können auf einem System mit etwa 400-500 VirtualHosts. Aber ich habe keine Bedenken, das sich der Ansatz von der Performance her merklich zum normalen PHP-CGI-Verfahren unterscheiden wird.

Man sollte aber wohl drauf achten, dass das neue Wrapper-Script vernünftige Rechte besitzt um sich darüber kein Sicherheitsproblem zu schaffen. Auch weiß ich nicht, in wie weit man allen Umgebungsvariablen trauen kann, die der Apache beim Start des Scripts setzt. Ich denke, DOCUMENT_ROOT z.B. ist eher unkritisch, da es direkt aus der VirtualHost-Konfiguration genommen wird. Aber Inhalte aus Variablen zu verarbeiten, die der Client selber beeinflussen kann sollte man vielleicht wenn möglich vermeiden. Oder bin ich wieder zu paranoid?


----------



## Till (5. Dez. 2007)

> Aber Inhalte aus Variablen zu verarbeiten, die der Client selber beeinflussen kann sollte man vielleicht wenn möglich vermeiden. Oder bin ich wieder zu paranoid?


Da sollte man lieber zu vorsichtig sein, sonst darf man später seinen Server entwanzen


----------



## HarWee (10. Dez. 2007)

Ich habe den Wrapper getestet, und es Funktioniert ganz gut. Außer das dadurch Datei- Uploads nicht mehr funktionieren. 
Hab folgendes im php5-wrapper geändert:

#!/bin/sh
BASEDIR=`/usr/bin/dirname ${DOCUMENT_ROOT}`
/usr/bin/php5-cgi -d open_basedir=$BASEDIR -d upload_tmp_dir=$BASEDIR/phptmp


----------



## sqrt (10. Dez. 2007)

Ja, das wäre jetzt auch mein Vorschlag gewesen. Wie weiter oben im Thread schon erwähnt kann man über den Wrapper-Ansatz beliebige Variablen aus der php.ini setzen. So z.B. auch den Session-Save-Path. Das hat dann auch den Vorteil, das die temporären Session-Dateien nicht alle in einem großen Ordner rumfliegen sondern nach Usern getrennt...



> #!/bin/sh
> 
> BASEDIR=`/usr/bin/dirname ${DOCUMENT_ROOT}`
> TMPDIR=${BASEDIR}/phptmp
> ...


Netterweise wird ja von ispConfig schon ein phptmp-Verzeichnis angelegt. Dann sollte man das auch nutzen.

Wer lieber das alte Verhalten beibehalten möchte und für alles /tmp nutzen will, der kann auch den Pfad /tmp zusätzlich an die Variable open_basedir anhängen:



> -d open_basedir=${BASEDIR}:/tmp


Das kann man sehr flexibel handhaben...


----------



## xwsnet (10. Dez. 2007)

Ich habe zu dem Script nochmal eine Frage. Und zwar wenn ich BASEDIR=`/usr/bin/dirname ${DOCUMENT_ROOT}` schreibe, muss ich dann statt /usr/bin/dirname das Verzeichniss angeben, in dem die Webs gespeichert sind? Oder soll das so bleiben?

Denn ich würde das gerne einsetzen, wenn das Script auch bei anderen läuft...

Danke schon mal für die Hilfe


----------



## Till (10. Dez. 2007)

> Oder soll das so bleiben?


Das soll so bleiben. Es ist ein Befehl, der das Verzeichnis bestimmt. Wenn Du es für jedes Web ändern müsstest, würde das Wrapper Script nicht so viel Sinn machen bzw. eine so elegante Lösung sein.


----------



## sqrt (11. Dez. 2007)

> # man dirname


sollte etwas mehr Klarheit darüber, was der Befehl macht, schaffen. ;-)

Kurz: Dieser Befehl interpretiert den übergebenen Parameter (im obigen Beispiel den Inhalt der Variablen DOCUMENT_ROOT) als Pfadangabe und schneidet den hinteren Teil weg, so daß nur noch das Verzeichnis übrigbleibt, in dem sich die Datei, auf die sich der übergebene Pfad bezieht, befindet.


----------



## xwsnet (11. Dez. 2007)

Klasse!
So lernt man doch immer wieder dazu...

Nochmals Danke


----------



## xwsnet (11. Dez. 2007)

So, ich hab das jetzt einmal ausprobiert, und wenn ich für das Wrapper-Script das folgende einsetze:



> #!/bin/sh
> 
> BASEDIR=`/usr/bin/dirname ${DOCUMENT_ROOT}`
> TMPDIR=${BASEDIR}/phptmp
> ...



dann kommt folgender Fehler:



> *Internal Server Error*
> 
> Could not execute script "/var/www/web10/web/index.php"
> suPHP 0.6.2


Was mache ich falsch???


----------



## Till (12. Dez. 2007)

Poste bitte mal den output von:

ls -la  /usr/bin/php5-cgi


----------



## xwsnet (12. Dez. 2007)

Klar, hier ist der Output:



> -rwxr-xr-x 1 root root 5583568 2007-11-12 19:01 /usr/bin/php5-cgi



mfg


----------



## Till (12. Dez. 2007)

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 (12. Dez. 2007)

Zitat von Till:


> 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





Zitat von Till:


> 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)
> ...


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


----------



## Till (12. Dez. 2007)

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

chmod +x namedeswrapperscriptes.sh

setzen


----------



## xwsnet (12. Dez. 2007)

Zitat von Till:


> Das Wrapperscript muss ja durch suphp gestartet werden, dazu benötig es ausführungs Berechtigungen.


Das war der Fehler. Jetzt funktioniert es einwandfrei 
Danke für die schnelle Hilfe


----------



## sqrt (16. Dez. 2007)

*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
> ...


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



> SetEnv php_safe_mode On


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";
> ...


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 (16. Dez. 2007)

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 (16. Dez. 2007)

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...


----------



## Damian (17. Dez. 2007)

*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


----------



## TauTau (13. März 2008)

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?


----------



## sqrt (13. März 2008)

Poste mal das komplette Script bitte... dann wird es einfacher, den Fehler zu sehen. Ansonsten macht es keinen Sinn, BASEDIR=$BASEDIR zu setzen, wenn die Variable 'use_pear' nicht gesetzt ist.



> if [ X"${use_pear}" == X"On" ]; then
> BASEDIR=${BASEDIR}:/usr/share/php
> fi


----------



## Till (13. März 2008)

Versuch doch mal:

BASEDIR="$(BASEDIR):/usr/share/php"


----------



## TauTau (13. März 2008)

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:


```
#!/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}
```


----------



## Feanwulf (17. März 2008)

Mal ne doofe frage:

Kann ich für ein einzelnes Hosting suPHP ausschalten?


----------



## Till (17. März 2008)

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 (18. März 2008)

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 (11. Juni 2009)

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:


```
#!/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


----------



## Till (11. Juni 2009)

> 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


Die User Webs unterstützen ja auch kein Scripting.


----------



## celocore (11. Juni 2009)

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


----------



## Till (12. Juni 2009)

Deshlab hab Ich Dir ja geschrieben, dass Dein setup nicht empfehlenswert ist. Du kannst auf einem halbwegs sicher konfigurierten Server nicht mit einem globalen typo3 source Verzeichnis arbeiten das außerhalb des web roots liegt. Das Problem ist einfach dass Du den falschen Ansatz bei der typo3 Installation genommen hast, eine Installation in /var/www/typo3 kannst Du nur nehmen wenn Du nicht mehr als eine Website hast Die dann auch genau in /var/www liegen soll.


----------



## celocore (12. Juni 2009)

Hallo Till,

jetzt habe auch ich den Bezug mit dem nicht empfehlenswerten Setup verstanden  ... thx


----------

