[PHP] Rootdir van een site / problemen met include e.d.

[Massiefje]

Beste mede programmeurs,

Wederom twijfel ik of dit in Professional Servers en Webhosting of in Programming hoort, maar ik probeer het hier, want ik denk dat het een direct PHP probleem/bug ding is.

Het gaat om het volgende. Op mijn Windows Server 2008 R2 hebben we IIS + PHP 5.3.6 draaien. Dit werkt in principe prima, met uitzondering dat Joomla 1.7 niet lekker functioneerde. Ik heb dus geupgrade naar PHP 5.3.8. en voila, Joomla 1.7 werkte prima.

Echter, ik ben iets tegengekomen, wat ik niet snap en waar ik via Google en php.net niet zo 123 uit kan komen. Het gaat om het volgende:

Een klant heeft op haar website een scriptje staan, dat de huidige directory uitleest d.m.v.

code:

opendir('.');

Met php 5.3.6 pakt hij dan de huidige map (een submap in de root) waar het scriptje in staat en kan dan door alle bestanden en mappen uit die map bladeren. Echter, na het upgraden naar 5.3.8 (en de config file aanpassen naar onze wensen en zoals het bij 5.3.6 ook was) werkt dit niet meer. De bovenstaande code komt namelijk uit op de map waarin php-cgi.exe draait.

Ik ben verder gaan testen en ook Wordpress sites werken door dit probleem niet meer. Het lijkt alsof de root van de site ineens de PHP map is geworden waardoor een include als

code:

include('./wp-header.php');

dus niet meer gevonden wordt.

Waar zit hem dit probleem ?

Zoals gezegd al gezocht op Google op zaken als rootdir, basedir, etc etc. Open_basedir is iets wat veel naar voren komt, maar dit stukje lijkt enkel geschikt om aan te geven waar een site wel en niet in mag komen. Met PHP 5.3.6 werkte dit al zonder config en komt men niet in de PHP map uit.

Verder (en dit heeft er misschien mee te maken) snap ik iets nog niet. Waarom werkt

code:

opendir('.');

wel op een submap, maar niet op de root van de site ? Ik krijg dan een access denied. Alle mappen en bestanden hebben dezelfde rechten. Bestanden openen in de root werkt wel gewoon, maar bovenstaande code dus niet.

Ik hoop dat ik uitvoerig genoeg uitgelegd heb wat het probleem is en wat ik zelf al geprobeerd heb. Debuggen is over het algemeen geen probleem, maar hier kom ik echt niet uit.

Alvast bedankt!

<sub>Aan de mods: ik blijk nogal eens een topic te openen dat niet aan de eisen voldoet. Mocht dit nu weer zo zijn, mijn excuses, ik doe echt mijn best door zelf onderzoek te doen en alleen zaken te posten die er toe doen. Zoveel mogelijk informatie te geven, FAQ's doorlezen, etc etc. Heb zelfs een van de moderators toegevoegd op MSN om me vooraf te laten informeren, maar deze persoon is niet online.

Teach me, don't punish me.</sub>

[MueR]

Het gebruiken van relatieve paden is altijd risicovol. Daarbij is het algemeen bekend gedrag (hoewel niet handig). In plaats van opendir('.') zou je opendir(__DIR__) kunnen gebruiken.

[Massiefje]

MueR schreef op donderdag 29 september 2011 @ 13:12:
Het gebruiken van relatieve paden is altijd risicovol. Daarbij is het algemeen bekend gedrag (hoewel niet handig). In plaats van opendir('.') zou je opendir(__DIR__) kunnen gebruiken.

Ik heb dit nagelezen en zojuist getest.

code:

opendir(__DIR__);

Werkt, maar doet hetzelfde als

code:

opendir('.');

Tevens werkt ook dit niet in de root van de site, krijg dan de error:

code:

Warning: opendir(D:\wpsites\user\domain.nl\site\wwwroot,D:\wpsites\user\domain.nl\site\wwwroot) [function.opendir]: Access is denied. (code: 5) in D:\wpsites\user\domain.nl\site\wwwroot\test2.php on line 7

_{Username en domeinnaam even vervangen door resp. user en domain.nl}

[naam]

Probeer eens:

PHP:

opendir(dirname(__FILE__));

[Massiefje]

naam schreef op donderdag 29 september 2011 @ 13:21:
Probeer eens:

PHP:

opendir(dirname(__FILE__));

Zelfde fout helaas.....

[naam]

Wat krijg je als output als je

PHP:

echo dirname(__FILE__);

doet?

[ Voor 3% gewijzigd door naam op 29-09-2011 13:24 ]

[Massiefje]

naam schreef op donderdag 29 september 2011 @ 13:24:
Wat krijg je als output als je

PHP:

echo dirname(__FILE__);

doet?

Dan krijg ik:

code:

D:\wpsites\user\domain.nl\site\wwwroot

[naam]

Heeft php wel lees/schrijfrechten in de map die je probeert te openen?

[Verwijderd]

Je error duidt er mijns inziens op dat je er simpelweg niet voldoende rechten aan hebt gegeven.

[Massiefje]

naam schreef op donderdag 29 september 2011 @ 13:29:
Heeft php wel lees/schrijfrechten in de map die je probeert te openen?

code:

fopen('/test.txt', 'r');

werkt prima. Dus de rechten moeten goed zijn.

[BCage]

Kun je dit eens proberen:

PHP:

opendir(dirname(__FILE__)."\.");

[Massiefje]

BCage schreef op donderdag 29 september 2011 @ 13:49:
Kun je dit eens proberen:

PHP:

opendir(dirname(__FILE__)."\.");

Zelfde foutmelding: access denied....

Wat ik er ook nog even bij wil vermelden: om rechten uit te sluiten, heb ik ook al getest om gebruikersgroep EVERYONE alle lees en schrijfrechten te geven.

Uitslag: zelfde foutmelding

[Matis]

Ik ben ook tegen problemen met een opendir icm Windows Server 2008 aangelopen.

Ik weet even niet meer wat het probleem was, maar ik zal het opzoeken. Het was echt een ontzettend lullig iets. Een gedocumenteerde fout in de PHP-functionaliteit.

[BCage]

Ja, ik had deze bug gevonden, waar ook de bovenstaande workaround in genoemd stond. Een andere workaround die daar wordt genoemd is om een subdirectory van de root te openen en daar achter dan '..' te zetten. Dus als er een directory 'bla' is in de root, kun je het volgende proberen:

PHP:

opendir("D:\wpsites\user\domain.nl\site\wwwroot\bla ..");

[Massiefje]

BCage schreef op donderdag 29 september 2011 @ 14:44:
Ja, ik had deze bug gevonden, waar ook de bovenstaande workaround in genoemd stond. Een andere workaround die daar wordt genoemd is om een subdirectory van de root te openen en daar achter dan '..' te zetten. Dus als er een directory 'bla' is in de root, kun je het volgende proberen:

PHP:

opendir("D:\wpsites\user\domain.nl\site\wwwroot\bla ..");

Ik was aan het typen dat de workaround NIET werkte, maar toen ik zag dat er achter 'bla' geen \ stond (en die dus in mijn code weggehaald heb), werkte het blijkbaar wel! Maar...... als ik dan door de files/folders heen scroll, zit ik toch in de map \bla helaas. Die .. doen dus blijkbaar niets.

Tevens zouden we het 'belangrijkste' vergeten. Waarom komt

code:

opendir('.');

in de map d:\php uit..... en niet in de wwwroot van de site ?

Als ik dat laatste opgelost krijg, heb ik voor 99% van mijn klanten al een oplossing draaien namelijk.

Edit:
Ik kwam op internet ook dit tegen

code:

chdir(dirname(__FILE__));
$handle = opendir('.');

Dit moet dan map veranderen naar de huidige map (uiteraard), maar ook dat mag niet.....

Ik snap het echt niet meer

[ Voor 9% gewijzigd door Massiefje op 29-09-2011 15:49 ]

[ytterx]

omdat PHP vanuit die map wordt uitgevoerd. "." is de "huidige" locatie

[Matis]

Daar komt volgens mij de nukken van Windows om de hoek kijken.

Het verschil zit hem volgens mij in het feit dat wanneer Windows een applicatie als service start, die per definitie vanuit OF C:/Windows/System32/ werkt OF vanuit de execute van de gestarte service.

Als Windows PHP als user-proccess draait, dan zal het hoogstwaarschijnlijk vanuit de map waarin het PHP-script staat werken.

[Massiefje]

Matis schreef op donderdag 29 september 2011 @ 15:49:
Daar komt volgens mij de nukken van Windows om de hoek kijken.

Het verschil zit hem volgens mij in het feit dat wanneer Windows een applicatie als service start, die per definitie vanuit OF C:/Windows/System32/ werkt OF vanuit de execute van de gestarte service.

Als Windows PHP als user-proccess draait, dan zal het hoogstwaarschijnlijk vanuit de map waarin het PHP-script staat werken.

Dit zou ik als waarheid aannemen, als het nooit heeft gewerkt. Ik ben teruggegaan naar PHP 5.3.6, zodat mijn klanten even geen nukken ondervinden, maar..... daar werkt het prima.

code:

opendir('.');

opent netjes de huidige map waaruit het SCRIPT is opgestart.

Onder PHP 5.3.8 opent hij dus d:\php.......

[Massiefje]

Niemand die hier verder nog iets nuttigs over kan zeggen.

Kortom herhaling over wat er mis gaat of wat ik niet kan uitleggen:

code:

opendir('.');

Opent de d:\php map en niet de current map waar men in zit (bij oudere PHP versies wel, waarom ?)

En waarom kan ik geen

code:

opendir('.');

doen in de root van een site, maar wel in een submap ? Er komt een access denied bij de root.

Het maakt niet uit hoe het geschreven wordt, oftewel via $_SERVER['Document_Root'] oftewel via andere vormen van de huidige dir achterhalen. Het openen van de rootdir (om door files heen te bladeren bijvoorbeeld) is niet mogelijk.

Wie kan me helpen?

[Phoenix1337]

Massiefje schreef op zondag 02 oktober 2011 @ 15:15:

En waarom kan ik geen

code:

opendir('.');

doen in de root van een site, maar wel in een submap ? Er komt een access denied bij de root.

Het maakt niet uit hoe het geschreven wordt, oftewel via $_SERVER['Document_Root'] oftewel via andere vormen van de huidige dir achterhalen. Het openen van de rootdir (om door files heen te bladeren bijvoorbeeld) is niet mogelijk.

Wie kan me helpen?

Omdat php geen rechten op de rootmap heeft maar wel op alle bestanden die erin staan.

[GlowMouse]

Massiefje schreef op donderdag 29 september 2011 @ 15:22:
[...]


Ik was aan het typen dat de workaround NIET werkte, maar toen ik zag dat er achter 'bla' geen \ stond (en die dus in mijn code weggehaald heb), werkte het blijkbaar wel! Maar...... als ik dan door de files/folders heen scroll, zit ik toch in de map \bla helaas. Die .. doen dus blijkbaar niets.

Tevens zouden we het 'belangrijkste' vergeten. Waarom komt

code:

opendir('.');

in de map d:\php uit..... en niet in de wwwroot van de site ?

http://nl3.php.net/getcwd
De chdir zal wel falen op basis van permissies.

[Massiefje]

De current working directory (goede zoekterm!) heeft me het volgende opgeleverd tot nu toe (maar ik ga nog verder zoeken)

code:

echo getcwd();

levert op de oude PHP versie (5.3.6) op:
d:\wpsites\user\domain.nl\site\wwwroot

op de nieuwe versie van php (5.3.8) levert het het volgende op:
d:\php

Ik heb ook gekeken of de SAPI hetzelfde is en dat is het geval, via:

code:

echo php_sapi_name();

Deze zijn beide:
cgi-fcgi (fastCGI onder IIS dus)

Ik ben wel weer een stapje verder!

[Massiefje]

Phoenix1337 schreef op maandag 03 oktober 2011 @ 20:48:
[...]


Omdat php geen rechten op de rootmap heeft maar wel op alle bestanden die erin staan.

Is dat gebruikelijk? Want zelfs als ik alle rechten toeken door gebruikersgroep EVERYONE full rights te geven, dan nog faalt het.

[djexplo]

Never mind on the workaround. Was related to some fastcgi caching. If you are running fastcgi the parent directory check is only done the first time. If it has access the first time it won't check the parent directory for further accesses.

https://bugs.php.net/bug.php?id=43817

[ Voor 91% gewijzigd door djexplo op 04-10-2011 15:42 ]

[Massiefje]

edit: ik was te snel met reageren blijkbaar, ga nu het topic doorlezen!

Ok, het openen van de root is dus een bekend probleem bij PHP. Dat wachten we nog ff af.

Nu het probleem van de CWD nog..... Dat blijft mijn grootste struikelblok ook overigens, aangezien zelfs Wordpress niet wil draaien. Die required namelijk files via

code:

require('./file.php');

(als voorbeeld)

[ Voor 150% gewijzigd door Massiefje op 04-10-2011 16:16 ]

[GlowMouse]

De cgi zal de cwd wel willen wijzigen, maar loopt daar wellicht tegen hetzelfde probleem op. In die bugreport staan twee oplossingen:
- php-5.2.17-nts-Win32-VC6-x86 draaien
- permissies op bovenliggende mappen toekennen aan het php-proces

[Massiefje]

Het probleem van de rootdit lijkt opgelost te zijn!

Het was (uiteraard) een fout van mijzelf. Ik had de Threat Safe versie geinstalleerd, terwijl ik de Non Threat Safe versie hiervoor gebruikte (en daar dus alles op ingericht had!)

Nu draait versie 5.3.8 dus prima, en de CWD is gewoon de huidige map!

Dank jullie allen!