Syntax für open_basedir

[yavhcsu]

Ich habe im Bezug auf die Direktive php_admin_value open_basedir bei php 4 bzw. 5 hier ein Phänomen, was ich nicht so recht einordnen kann.

Zwei Installationen mit Ubuntu 6.06, jeweils mit PHP4 und PHP5. Unter /etc/apache2/sites-available befinden sich die gleichen conf Dateien u.a. mit ein und derselben Konstruktion:

<Directory ...>
php_admin_value open_basedir "/var/www/meinpfad/:/tmp/:/usr/share/php/"
</Directory>

Bei PHP4 gibt es mit dieser Direktiven mit Zugriff aus PHP auf Dateien, die in /tmp abgelegt werden, kein Problem. Bei PHP5 schon. Hier wird witzigerweise gemeckert, Open Base Restriction is in effect und "/tmp" wäre nicht innerhalb von "/var/www/meinpfad/:/tmp/:/usr/share/php/". Allerdings ist der Zugriff auf meinpfad dennoch zulässig.
So witzig war es zunächst auch nicht, bis ich drauf gekommen bin:

<Directory ...>
php_admin_value open_basedir "/var/www/meinpfad:/tmp:/usr/share/php"
</Directory>

Der nachfolgende Schrägstrich bei jedem Verzeichnis weglassen, dann greift die Direktive vollständig.

Ich habe mal php.net gecheckt, da steht es so wie ursprünglich geschrieben.
Hat da jemand 'ne Erklärung dafür. Klar ist mir, dass hier nur Präfixe angegeben werden und dass der abschliessende Schrägstrich eigentlich lediglich anstelle des Präfix ein konkretes Verzeichnis angeben soll. Aber warum wird die Direktive mit diesen abschließenden Schrägstriche nur bei PHP4 scheinbar vollständig interpretiert.

 

[CentY]

Diese Frage habe ich mir auch gestellt ... Wir sollten vorallem die VHCS Domaintemplates dem entsprechend anpassen, da hier sowohl unter Debian als auch unter Ubuntu mit den Standardtemplates garnichts geht weil da ja /tmp/ in der open_base_dir steht.

Aber das Phänomen kenn ich und hat mich schon oft zur Weißglut getrieben allerdings tritt dieses Phänomen auf Debian Etch erst seit ein paar Monaten auf also scheint es nicht generell an PHP5 zu liegen.

Grüße

 

[yavhcsu]

Also, ich bin nun das erste Mal darüber gestolpert. Solange der erste Teil bis zum ersten Doppelpunkt bzw. abschliessenden Schrägstrich korrekt interpretiert wird, dürften ja einige PHP-Projekte noch laufen. Aber nun habe ich PHP-Projekte wie egroupware, die eben auch in /tmp Zwischenprodukte ablegen möchten, z.B. der beim Hochladen eines Anhang in einer neuen email in felamimail. Das Symptom ist das schlichte Versagen der Ausführung der Funktion ohne jegliche Fehlermeldung oder Logeintrag. Hier wird ja noch die Funktionsbibliothek PEAR als Aufsatz auf PHP verwendet. Gaaanz tolle Fehlersuche. Ich konnte es erst einkreisen, als nach einem Login im filemanger von VHCS mal ein paar Hinweise kamen.

Wenn das mit PHP4 ebenfalls so zutrifft, liege ich wohl mit den Updates auf der bisher problemos laufenden Installation wohl etwas zurück. Es ist scheinbar so, dass es eine ganz bestimmte Konstellation / Update gibt, wobei die Auswertung der Direktive bei abschliessendem Schrägstrich vor einem Doppelpunkt endet, unabhängig was hiernach noch folgt.

Was die templates von VHCS angeht, nun das kann man umgehen, klar. Aber nach der Doku von PHP.net ist die Verwendung des abschliessenden Schrägstrichs eben vorgesehen.

 

[CentY]

Es geht sogar noch weiter ... Ich habe in VHCS mittlerweile /tmp und /tmp/ stehen da manche Scripts sonst wieder meckern sie können nicht in /tmp/ schreiben wegen open_base_dir ... Für mich zeigt das wieder wie schlecht PHP eigentlich ist, keiner hält sich hier an irgendwas. So hatte ich neulich auch das Problem dass ein Array was mit festen Werten in einer festen Reihenfolge bestückt wird bei der Ausgabe über foreach völlig wirr ausgegeben wird. Soviel dazu ...

 

[combie]

So hatte ich neulich auch das Problem dass ein Array was mit festen Werten in einer festen Reihenfolge bestückt wird bei der Ausgabe über foreach völlig wirr ausgegeben wird.

Sorry, aber das glaube ich erstmal nicht!
Du hast das bestimmt irgendein sort übersehen.

Für mich zeigt das wieder wie schlecht PHP eigentlich ist, keiner hält sich hier an irgendwas.

Ja, der Rundumschlag...
Wenn wirklich PHP im Kern Schuld ist, dann setze einen Bugreport ab. Sowas wird schnell behoben.
Aber meist dürften es schlampig geschriebene Scripe sein, welche Probleme verursachen. Und dafür darfst du PHP nicht verantwortlich machen. Wenn du eine Handgranate im Handschuhfach deines Autos zündest, willst du dann den Fahrzeughersteller anmaulen, weil danach das Licht rechts vorn nicht mehr geht?

Fazit:
Ich will nicht ausschließen, dass die genannten Probleme wirklich existieren. Aber die bisher gelieferten sach- und fachlichen Informaltionen sind nicht ausreichend, um eigene Tests zu fahren oder den Bugreport zu befragen. Ich für meinen Teil arbeite mit verschiedensten PHP/OS Versionen und Konfigurationen, aber das hier beanstandete ist mir bisher noch nicht untergekommen.
Schlampige Scripte allerdings schon!
!! viele !!

 

[CentY]

Das kannst du soviel nicht glauben wie du willst Hier tritt das Phänomen unter PHP5 auf Debian Etch auf, unter CentOS und PHP5 passiert es mit dem gleichen Array nicht und unter XAMPP auch nicht und unter PHP4 auch nicht nur eben auf dem Debian System. Solche Sachen sind mir schon öfter passiert und keiner glaubt es bis ich es Ihnen zeige. Derzeit versuchen sich an meinem Problem 10 Leute um es nach zu voll ziehen

Desweiteren gibt es unter PHP noch andere lustige Probleme was move_uploaded_file angeht und die sind sogar auf php.net beschrieben, dass hier die Rechte teilweise nur richtig gesetzt werden wenn /tmp auf einer anderen Partition liegt. Die Rechte sonst sind 0600 mit dem User Webserver obwohl es sich um eine FCGI Umgebung handelt.

I have the same problem as the person two comments below me. When I use the move_uploaded_file function the permissions for the file are set to 0600. No matter what configurations you set.

I searched the internet and I found more people with the same problems, but no solutions. I set the umask of apache to 013 and still the files were set to 0600.

The copy function solves the problem. Another way to solve this problem is using the chmod function after uploading.

Da gibt es dann teils wirklich haarsträubende Lösungen dafür:
pdadmin-forum | Anwendung | PHP Funktion "move_upload_file" und die Rechte
Hier werden sogar lokale Loopdevices angelegt um dieses Problem zu umgehen.

Außerdem sollte dies kein Rundumschlag gegen PHP sein ich habe nur meine Meinung kundgetan dass ich PHP persönlich nicht leiden kann, da es hier immer wieder zu Problemen kommt die sich keiner erklären kann oder selbst die Pros nicht mehr weiter wissen wieso dies nun auftritt. Ansonsten sag ich ja nix gegen PHP nen paar kleine Websites bastel ich ja genauso damit.

P.S.: Fühlt euch doch nicht immer gleich persönlich angegriffen wenn man was an eurer Lieblingssprache oder so zu meckern hat oO Is ja unerträglich.

Grüße

[/QUOTE]

 

[combie]

Und wieder wird ein Knüppel aus dem Sack geholt......

Nein PHP ist NICHT meine Lieblingssprache!
Es kriegt auch niemand von mir einen vor den Koffer, weil er auf irgendwas rumhackt.
Sondern: Die gelieferten Informationen sind zu wenig!!
Auch der von dir verlinkte Thread führt herzlich wenig Problemanalyse durch!
1. 0600 reicht vollkommen um eigene Dateien lesen zu können.
2. 0644 oder gar 0666 im Temp Ordner betrachte ich als Server Fehlkonfiguration
3. Dass PHP als FCGI kompiliert wurde, heißt noch lange nicht, dass es auch so aufgerufen wird.
4. irgendwelche hochgeladenen Dateien auf 0755 setzen zu wollen, ist voll dull




Also, wenn du dich nur ausheulen willst, dann sage das dabei....
Möchtest du allerdings Hilfe (von mir), dann lass die Heulerei und liefere Fakten.

Was helfen Zitate ohne Quellangaben... Grr..

 

[CentY]

Lesen ftw is von php.net

Ich frag mich was du dich hier so aufregst ... 0600 reicht eben nicht wenn es dann www-data:www-data gehört ... und nicht dem fcgi Benutzer der die Datei hochgeladen hat, danach kommt nämlich schlicht weg ein Zugriffsfehler wie in den Forenbeiträgen zu lesen.

Aber darum geht es in dem Thread auch nicht sondern um die Frage wieso man bei open_base_dir /tmp und /tmp/ angeben muss damit alle PHP Scripts zufriedenstellend laufen.

Und hier geht es ganz bestimmt nicht um ausheulen sondern um Fakten die mir an PHP aufgefallen sind und mir nicht gefallen wenn du Probleme damit hast halt dich aus dem Thread fern und mach hier nicht einen auf Moralapostel.

 

[Roger Wilco]

Lesen ftw is von php.net

Wenn ich dir einfach ein Zitat hinwerfe und dir nur die Webseite (ohne Deeplink) verrate, auf der dieses zu finden ist, würdest du danach suchen wollen?

Ich frag mich was du dich hier so aufregst ... 0600 reicht eben nicht wenn es dann www-data:www-data gehört ... und nicht dem fcgi Benutzer der die Datei hochgeladen hat, danach kommt nämlich schlicht weg ein Zugriffsfehler wie in den Forenbeiträgen zu lesen.

Konfigurationsfehler. Und wie combie schon angemerkt hat, gibt es einen Unterschied, ob ein Skript direkt über die (Fast)CGI-Schnittstelle aufgerufen wird oder noch SuExec dazwischenhängt.

Aber darum geht es in dem Thread auch nicht sondern um die Frage wieso man bei open_base_dir /tmp und /tmp/ angeben muss damit alle PHP Scripts zufriedenstellend laufen.

Weil es keine Funktion wie is_dir_in_open_basedir() gibt, sondern du das selbst prüfen musst. Die jeweiligen Skripte besorgen sich den Werte z. B. per ini_get() und prüfen dann, ob das von ihnen gewünschte Verzeichnis darin vorkommt. Manche eben mit trailing slash, manche ohne. Letztendlich lässt sich das dann wieder auf den Skriptprogrammierer abwälzen, weil er ein dämliches Matching verwendet.

wenn du Probleme damit hast halt dich aus dem Thread fern und mach hier nicht einen auf Moralapostel.

Nur wenn du weniger auf Heulsuse machst.

 

[CentY]

Das Script selber meckert doch garnicht das es nicht funktioniert wenn du mal richtig gelesen hättest ... Sondern es tritt nur eine PHP Warning auf die besagt das /tmp gegen die Open_base_dir restrictions verstößt.

Ich dachte wenn ich php.net erwähne im Zusammenhang mit move_uploaded_file ist jeder in dem Forum soweit in der Lage oben bei Functions selber move_uploaded_file einzugeben und die Beiträge zu lesen gut stimmt wohl nicht. Dann jetzt ein Link für euch: PHP: move_uploaded_file - Manual

FCGI wird in dieser Konfiguration direkt aufgerufen ohne suEXEC. Außerdem funktioniert das mit den Rechten in dem Moment wo ich /tmp auf einer anderen Partition habe dann hat das File komischerweise 0644. Du kennst meine Konfiguration nicht und gehst davon aus dass sie falsch ist auch wieder sowas.

Aber ich denke es bringt nichts sich hier darüber zu streiten wer alles damit einverstanden is wie ich mich über PHP äußere und wie nicht. Sondern nach einer Lösung für das Problem zu suchen bzw. eine Erklärung wie es zu diesem Fehler kommen kann.

Das hier sollte eine ganz normale Diskussion werden warum manche Sachen mit PHP nicht so funktionieren wie sie vorgeschrieben sind oder in den PHP Referenzen beschrieben und nicht persönliche Angriffe. Aber gut da sieht man mal wieder den Grundton wenn man nur seine Meinung kundtun will dass einem etwas an einem Opensourceprogramm nicht gefällt. Ich habe hier weder jemanden persönlich Angegriffen gehabt bis combie damit anfing mich anzugreifen noch sonst etwas. Ich verstehe euch nicht, könnt ihr nicht einmal sachlich bleiben? Davon werden die hier beschriebenen Probleme nämlich nicht gelöst.

 

[combie]

Die Probleme kann man nur lösen wenn man sachlich bleibt!

Rein praktisch gesehen, gibts einen Haufen hervorragend funktionierender PHP Installationen. Ganz sachlich: Wenn deine nicht so gut tut, dann könnte doch dort was im argen liegen. Also mußt du erstmal deine Konfiguraton in Frage stellen. Du darfst dir auch andere anschauen, vergleichen was dort eingestellt ist. Oder welche Verfahren dort angewendet werden.

FCGI wird in dieser Konfiguration direkt aufgerufen ohne suEXEC.

Ja, und wozu soll das gut sein?
Das macht doch nur halbwegs Sinn, wenn denn nur eine Domain gehostet wird..
Aber dann kannst du doch auch den Webserver unter dem User laufen lassen.
Und dann wäre mod_php auch keine falsche Wahl.



Wenn ich mir die von dir gelieferten Fakten so anschaue/auswerte, dann komme ich auf sowas:
PHP ist Mist, weil der Server Admin einen Bock geschossen hat
PHP ist Mist, weil der Webspace beim Billigheimer gemietet wird
PHP ist Mist, weil das Script schlampig geschrieben wurde
PHP ist Mist, weil es Bugs hat (aber welche Software, ausser TeX, ist schon 100% Bugfrei)

 

[yavhcsu]

Die Probleme kann man nur lösen wenn man sachlich bleibt!

Schade nur, dass Du schon in Deinem ersten Post hier nicht nicht wirklich was zur Sache geschrieben hast, sondern lediglich auf ein eher nebensächliches Statement von @Centy eingegangen bist.
@RogerWilco: Also, Deinen Post sehe ich als schon fast als flaming - nicht mal ein einziges Wort zum eigentlichen Problem

Nochmal zurück zur eigentlichen Diskussion. Als ich meinen Thread absetzte, hatte ich ursprünglich die Hoffnung, dass irgendjemand mir einen Tipp geben könnte, was die eigentliche Ursache hierfür ist.

Ich habe zwei Installationen mit Ubuntu 6.06 und sogar das gleiche PHP-Projekt drauf und im Bezug auf diese Direktive zumindest exakt die gleiche Konfiguration. Ich habe diese in meinem Post aufgeführt.

Bereits ein Hinweis auf das, was noch an Angaben fehlt hätte mir ja schon geholfen. Denn so wüsste ich ja, welche Abhängigkeiten ich noch prüfen müsste.

Grundsätzlich, so denke ich, steht es jedem frei, seine Meinung kund zu tun. Aber doch bitte zumindest ein Statement zur Sache, danke!

 

[yavhcsu]

Ergänzende Info

Ich verwende bei beiden Installation php-mod.

Die Fehlermeldung "open base dir restriction is in effect" kommt IMHO direkt vom PHP-Interpreter (hier php-mod).
Es dürfte daher zunächst mal unerheblich sein, ob da im Script ein Fehler ist oder nicht. Klar ist, wenn das Script auf eine Datei oder Verzeichnis außerhalb des docroot zugreifen möchte und der Weg dorthin nicht mit der in open_basedir explizit angegebene Präfixe/verzeichnisse übereinstimmt, eine Fehlermeldung generiert wird.

Wie schon oben zitiert, hier nun die komplette Fehlermeldung

Warning: ftp_rawlist() [function.ftp-rawlist]: open_basedir restriction in effect. File(/tmp) is not within the allowed path(s): (/var/www/vhcs2/gui/tools/filemanager/:/tmp/:/usr/share/php/) in /srv/var/www/vhcs2/gui/tools/filemanager/ftp.php on line 108

Also befindet sich das Verzeichnis

/tmp

eigentlich innerhalb der erlaubten Pfade

/var/www/vhcs2/gui/tools/filemanager/:/tmp/:/usr/share/php/

wenn man nach der Doku auf PHP.net geht. Oder sieht hier jemand einen Tippfehler?
Ohne die abschließenden Schrägstriche läuft alles bestens und ohne Fehlermeldung. Bei der anderen abgesehen von PHP4/MYSQL4 gleichartigen Installation werden die abschliessenden Schrägstriche korrekt berücksichtigt.

 

[Roger Wilco]

@RogerWilco: Also, Deinen Post sehe ich als schon fast als flaming

Ich nicht, aber es erwartet auch niemand, dass du meiner Meinung bist oder dass ich deiner Meinung bin.

/var/www/vhcs2/gui/tools/filemanager/:/tmp/:/usr/share/php/

wenn man nach der Doku auf PHP.net geht. Oder sieht hier jemand einen Tippfehler?

The restriction specified with open_basedir is actually a prefix, not a directory name. This means that "open_basedir = /dir/incl" also allows access to "/dir/include" and "/dir/incls" if they exist. When you want to restrict access to only the specified directory, end with a slash. For example: "open_basedir = /dir/incl/"

Soviel dann auch zu dem Vorwurf, das Verhalten von PHP wäre in diesem Punkt willkürlich.

 

[combie]

Bereits ein Hinweis auf das, was noch an Angaben fehlt hätte mir ja schon geholfen.

Damit ich überhaupt abschätzen kann, was da und warum passiert, fehlen Angaben!
Ja!
1. Die konkrete PHP Version
2. Der betreffende Auszug aus der phpinfo() Ausgabe
3. Ein testbarer, diesen Fehler verursachender PHP Code Ausschnitt
4. Die unverstümmelte Fehlermeldung
5. Eine echo Kontrollausgabe des angesprochenen/fehlerverursachenden Pfades
All dieses wird wohl nötig sein um einen Konfigurations oder Script Fehler ausschließen zu können.

Und ich weiß nicht genau welches Handbuch du dazu gelesen hast, aber meins sagt dazu:

The restriction specified with open_basedir is actually a prefix, not a directory name. This means that "open_basedir = /dir/incl" also allows access to "/dir/include" and "/dir/incls" if they exist. When you want to restrict access to only the specified directory, end with a slash. For example: "open_basedir = /dir/incl/"

PHP: Safe Mode - Manual
Und so hat es bisher bei mir auch immer funktioniert.

---------------------

File(/tmp) is not within the allowed path(s)

Du greifst auf /tmp zu, hast aber nur /tmp/ erlaubt!
Welche ein Wunder, dass es knallt!

 

[yavhcsu]

Danke für die Infos:

@RogerWilco:
Zitat von PHP: Safe Mode - Manual

Under Windows, separate the directories with a semicolon. On all other systems, separate the directories with a colon. As an Apache module, open_basedir paths from parent directories are now automatically inherited.

Also demnach ist eine Aufzählung von Präfixen und/oder Verzeichnissen (also mit abschliessendem Schrägstrich) zulässig. Das steht an gleicher Stelle, eben nur ein Stückchen höher. Der abschliessende Schrägstrich ist demnach nicht als Abschluss der Direktive zu verstehen.

@combie
Zunächst die problemlos funktionierende Installation:
1. PHP 4.4.2-1build1
2.

open_basedir	/var/www/virtual/example.com/egroupware/:/usr/share/php/:/tmp/:/var/www/virtual/example.com/egroupware/filepile/:/var/www/virtual/example.com/egroupware/temp/

Dann die Problembehaftete Installation:
1. PHP Version 5.1.2
2a. PHPInfo beim Auftritt des Fehlers:

open_basedir	/var/www/virtual/example.com/login/:/usr/share/php/:/tmp/

2b. PHPInfo wenn kein Fehler aufritt:

open_basedir	
/var/www/virtual/example.com/login:/usr/share/php:/tmp

3.

        $files = ftp_rawlist ($fp, ".");

Die Variable $fp enthält zu diesem Zeitpunkt "/tmp"
4.

drwxrwxrwt   6 root root  4096 2008-10-05 15:24 tmp

Danke für den Hinweis mit dem Handbuch, aber auf die Quelle habe ich schon als "Deeplink" in meinem zweiten Post hingewiesen.
Es ist zwar alles in Englisch gehalten, liest sich IMHO wie folgt:
Unter Windows, trennt man die Verzeichnisse mit einem Semikolon. Auf allen anderen Systemen, trennt man die Verzeichnisse mit einem Doppelpunkt. Als apache Modul genutzt, open_basedir Pfade werden vom Eltern Verzeichnis nun automatisch vererbt.
Die Beschränkung, die mit open_basedir angegeben wird, ist derzeit ein Präfix, und kein Verzeichnis. Dies heisst also, dass "open_basedir = /dir/incl" ebenso den Zugriff auf "/dir/include" und "/dir/incls, sofern diese existieren, erlaubt. Sofern man den Zugriff nur auf das angegebene Verzeichnis beschränken möchte, ist ein abschliessender Schrägstrich anzufügen. Zum Beispiel: "open_basedir = /dir/incl/"

 

[combie]

int ftp_rawlist ( int $ftp_stream , string $Verzeichnis )

Es erwartet einen Integer um den ausgewählten Stream zu identifizieren.

Wenn du dann aber sagst:

Die Variable $fp enthält zu diesem Zeitpunkt "/tmp"

Nunja, dann ist das zumindest schon mal arg verwunderlich.

Noch verwunderlicher ist meines Erachtens nach, der Wunsch, überhaupt mit den FTP Funktionen lokale Verzeichnisse auslesen zu wollen....

 

[Roger Wilco]

http://bugs.php.net/bug.php?id=41779

 

[yavhcsu]

Du greifst auf /tmp zu, hast aber nur /tmp/ erlaubt!
Welche ein Wunder, dass es knallt!

Ich sehe hier aber keinen Widersprich zur Doku auf PHP.net. Ob nun /tmp oder /tmp/ dies stellt speziell beim Zugriff auf /tmp keine Beschränkung dar.
Ersteres liesse zusätzlich auch den Zugriff auf /tmp1, /tmp2, usw. zu, sofern dieses existieren würden. Das ist aber hier weder gewünscht noch ursprünglich konfiguriert. ist. Zweiteres beschränkt gem. der Doku den Zugriff explizit auf das Verzeichnis /tmp
Nun sollte die Funktion ftp_rawlist also mit dem Abruf der Inhalte in diesem Verzeichnis kein Problem haben.

Dann noch der Hinweis, dass es der ein und derselbe (schon recht alte) Code ist, der hier zur Ausführung kommt. Und auf der Installation mit PHP4 eben ohne Fehler.

Gibt es hier eine weggefallende Toleranz beim Wechsel der Angabe von einem abschliessendem Schrägstrich als Kennzeichnung eines Verzeichnisses? Ich verstehe den Zweiten Parameter der Funktion, der "." so, dass hier klar auf ein Verzeichnis hingewiesen wird, also die Angabe des abschliessenden Schrägstriches nicht notwendig ist.

Aber jetzt haben wir ja den dritten Unbekannten. "FTP LIST" ist hier implementiert. Hierzu wird sicherlich eine Libary genutzt. Welche? Gibt es hier Updates, wo diese eingebettete Funktion sich nun neuerdings zusätzlich außerhalb des angegebenen Verzeichnisses bewegt? Es gibt durchaus Konstellationen, wo dieses untersagt (chrooted) ist.

 

[yavhcsu]

Ergänzend sei anzufügen, dass hier auch php-Projekte wie egroupware drüber stolpern und das just an den Stellen, wo eben via FTP-Funktionen auf /tmp und andere Verzeichnisse zugegriffen werden soll.
Auch die hier zum Einsatz kommende PEAR Funktionsbibliothek stolpert über dieses Problem beim Upload von Email-Anhängen, jedoch unangenehmerweise gänzlich ohne Fehlermeldung.
Dies betrifft auch das Synchronsieren mit eGWOSync und Funambol, was zum teilweise bzw, gänzlich eingeschränkt ist.

Von der Logik wäre dies alles richtig, vorausgesetzt, es handelt sich bei dem Zugriff auf ein Verzeichnis, welches eben nicht in der open base_dir Direktive enthalten ist.

Ist hier evt. ein Sicherheitsloch an einer anderen Stelle gestopft worden?