Onderwerp: Php problemen na migratie dommel

Hoi,

Ik gebruik Gallery (gallery.sourceforge.net) als online foto album, dit
wordt bij dommel gehost.
Nu ze dit weekend zijn overgestapt van Red Hat 7.3 naar Red Hat EL 3
werkt m'n gallery niet meer en krijg ik volgende foutmelding.

Warning:
fopen(/usr/local/psa/home/vhosts/domein.be/httpdocs/fotos/albums/.users/userdb.dat.lock):
failed to open stream: Permission denied in
/usr/local/psa/home/vhosts/domein.be/httpdocs/fotos/platform/fs_unix.php
on line 55
Error: Could not open lock file
(/usr/local/psa/home/vhosts/domein.be/httpdocs/fotos/albums/.users/userdb.dat.lock)!


De gallery heeft anderhalf jaar zonder probleem gewerkt, ik dacht eerst
aan een probleem met de permissies doordat ze door de migratie userdata
moesten overzetten maar alle permissies staan nog ok.

Iemand enig idee?



Mvg,

JV

Johan V. wrote:
> Hoi,
>
> Ik gebruik Gallery (gallery.sourceforge.net) als online foto album, dit
> wordt bij dommel gehost.
> Nu ze dit weekend zijn overgestapt van Red Hat 7.3 naar Red Hat EL 3
> werkt m'n gallery niet meer en krijg ik volgende foutmelding.
>
> Warning:
> fopen(/usr/local/psa/home/vhosts/domein.be/httpdocs/fotos/albums/.users/userdb.dat.lock):
> failed to open stream: Permission denied in
> /usr/local/psa/home/vhosts/domein.be/httpdocs/fotos/platform/fs_unix.php
> on line 55
> Error: Could not open lock file
> (/usr/local/psa/home/vhosts/domein.be/httpdocs/fotos/albums/.users/userdb.dat.lock)!
>
>
> De gallery heeft anderhalf jaar zonder probleem gewerkt, ik dacht eerst
> aan een probleem met de permissies doordat ze door de migratie userdata
> moesten overzetten maar alle permissies staan nog ok.
>
> Iemand enig idee?
>
>
>
> Mvg,
>
> JV

Probeer eens een pad relatief aan de current working directory. Staat
safe mode aan? (normaal zou hij dat dan moeten zeggen dat open_basedir
in effect is)

RedShift said the following on 6/29/2004 5:15 PM:

> Probeer eens een pad relatief aan de current working directory. Staat
safe mode aan? (normaal zou hij dat dan moeten zeggen dat open_basedir
in effect is)


Safe mode staat (zoals voor de migratie) aan, vroeger had ik die
foutmelding niet.

Johan V. said the following on 6/29/2004 5:04 PM:
> Iemand enig idee?

Probleempje opgelost, lag toch aan permissies die veranderd waren door
de overzetting van bestanden naar de nieuwe server.

Bij gallery moet je niet enkel albums/ rwxrwxrwx geven maar ook alle
onderliggende directorys.
Indien je shell access hebt is dat rap op te lossen: chmod -R 777 albums/

Via ftp is het wat moeilijker omdat de meeste ftp clients geen recursive
chmod toelaten, ik heb een windows ftp client gevonden die dat wel kan:
Core FTP Pro

Hiermee lukt het.



Sorry voor de noise

Johan V. <johanverstr@msn.com> wrote:
> Johan V. said the following on 6/29/2004 5:04 PM:
>> Iemand enig idee?

> Probleempje opgelost, lag toch aan permissies die veranderd waren door
> de overzetting van bestanden naar de nieuwe server.

> Bij gallery moet je niet enkel albums/ rwxrwxrwx geven maar ook alle
> onderliggende directorys.
> Indien je shell access hebt is dat rap op te lossen: chmod -R 777 albums/

Leuk! Kan je cgi's (perl/python/...) uitvoeren? Dan kan iedereen die een
account heeft bij dommel, je albums overschrijven, je database
passwoorden lezen ...


Vriendelijke groeten,
Frank Louwers

--
!!! Nieuwe formules voor resellers !!!
Openminds bvba www.openminds.be
Tweebruggenstraat 16 - 9000 Gent - Belgium

Johan V. wrote:

> Indien je shell access hebt is dat rap op te lossen: chmod -R 777 albums/

777 ?

Héél gezond

--
Dressing up as a Goth doesn't mean you really are one...

Jean wrote:
> Johan V. wrote:
>
>> Indien je shell access hebt is dat rap op te lossen: chmod -R 777 albums/
>
>
> 777 ?
>
> Héél gezond
>

Wacht hé, (ben nieuw in de UNIX wereld), zouden de juiste permissies zijn:
rw-r-----

Octaal: 640

Denk ik... gebruiken op eigen risico

RedShift <redshift@pandora.be> wrote:
> Jean wrote:
>> Johan V. wrote:
>>
>>> Indien je shell access hebt is dat rap op te lossen: chmod -R 777 albums/
>>
>>
>> 777 ?
>>
>> Héél gezond
>>

> Wacht hé, (ben nieuw in de UNIX wereld), zouden de juiste permissies zijn:
> rw-r-----

> Octaal: 640

T gaat over een directory, dus je moet zeker +x hebben om erin te
kunnen.

Als er enkel files in staan die door een php/cgi-script gelezen worden
is 700 (rwx------) t veiligste. Als er ook html pages instaan, best 711
(rwx--x--x). (Soms zal 710 genoeg zijn, hangt beetje af van de
instellingen.)

Maar t punt is dat als het 777 moet zijn bij dommel, en andere klanten
op dezelfde server kunnen cgi's uitvoeren, dat waarschijnlijk wil zeggen
dat users in mekaars files kunnen schrijven en zo ...


Vriendelijke groeten,
Frank Louwers

--
!!! Nieuwe formules voor resellers !!!
! Tot 15 juni: promocode usn2: 10% korting !
Openminds bvba www.openminds.be
Tweebruggenstraat 16 - 9000 Gent - Belgium

frank@openminds.be wrote:
> RedShift <redshift@pandora.be> wrote:
>
>>Jean wrote:
>>
>>>Johan V. wrote:
>>>
>>>
>>>>Indien je shell access hebt is dat rap op te lossen: chmod -R 777 albums/
>>>
>>>
>>>777 ?
>>>
>>>Héél gezond
>>>
>
>
>>Wacht hé, (ben nieuw in de UNIX wereld), zouden de juiste permissies zijn:
>>rw-r-----
>
>
>>Octaal: 640
>
>
> T gaat over een directory, dus je moet zeker +x hebben om erin te
> kunnen.
>
> Als er enkel files in staan die door een php/cgi-script gelezen worden
> is 700 (rwx------) t veiligste. Als er ook html pages instaan, best 711
> (rwx--x--x). (Soms zal 710 genoeg zijn, hangt beetje af van de
> instellingen.)
>
> Maar t punt is dat als het 777 moet zijn bij dommel, en andere klanten
> op dezelfde server kunnen cgi's uitvoeren, dat waarschijnlijk wil zeggen
> dat users in mekaars files kunnen schrijven en zo ...
>
>
> Vriendelijke groeten,
> Frank Louwers
>
Waarom execute rights? Het zijn toch maar gewoon pagina's die ingelezen
worden en doorgespugt naar de lezer?

frank@openminds.be said the following on 6/30/2004 10:27 AM:
> Maar t punt is dat als het 777 moet zijn bij dommel, en andere klanten
> op dezelfde server kunnen cgi's uitvoeren, dat waarschijnlijk wil zeggen
> dat users in mekaars files kunnen schrijven en zo ...

Het gaat om gallery (gallery.menalto.com).
De gallery zelf is mbv htaccess passwd afgeschermd maar dat helpt niet
veel denk ik.

Misschien is er zoiets als open base dir voor cgi's?
Dan lukt dat toch niet.

Geef anders een poc cgi (harmless aub ) en ik probeer het eens uit.

frank@openminds.be wrote:

> RedShift <redshift@pandora.be> wrote:
>
>>Jean wrote:
>>
>>>Johan V. wrote:
>>>
>>>
>>>>Indien je shell access hebt is dat rap op te lossen: chmod -R 777 albums/
>>>
>>>
>>>777 ?
>>>
>>>Héél gezond
>>>
>
>
>>Wacht hé, (ben nieuw in de UNIX wereld), zouden de juiste permissies zijn:
>>rw-r-----
>
>
>>Octaal: 640
>
>
> T gaat over een directory, dus je moet zeker +x hebben om erin te
> kunnen.
>
> Als er enkel files in staan die door een php/cgi-script gelezen worden
> is 700 (rwx------) t veiligste. Als er ook html pages instaan, best 711
> (rwx--x--x). (Soms zal 710 genoeg zijn, hangt beetje af van de
> instellingen.)
>
> Maar t punt is dat als het 777 moet zijn bij dommel, en andere klanten
> op dezelfde server kunnen cgi's uitvoeren, dat waarschijnlijk wil zeggen
> dat users in mekaars files kunnen schrijven en zo ...
>
>
> Vriendelijke groeten,
> Frank Louwers
>

hmmmm... apache/php/cgi-bin zal meestal als nobody draaien, niet als
root. Dus als je moet schrijven in die files, kan je het vergeten met 700.

ik geloof niet dat je dingen kan uitvoeren buiten je toegewezen
directory... php heeft die vervelende eigenschap om veel te veel te
tonen zoals full paths enzo.

--
mailto: dj021587_NOSPAM@planetinternet.be
surfto: http://home.scarlet.be/~dj021587

RedShift <redshift@pandora.be> wrote:
>>
> Waarom execute rights? Het zijn toch maar gewoon pagina's die ingelezen
> worden en doorgespugt naar de lezer?

Het ging hem om de rechten op een directory dacht ik. Als je geen
execute rechten op een directory hebt, kan je er niet in (zelfs al heb
je leesrechten).



Vriendelijke groeten,
Frank Louwers

--
!!! Nieuwe formules voor resellers !!!
Openminds bvba www.openminds.be
Tweebruggenstraat 16 - 9000 Gent - Belgium

Johan V. <johanverstr@msn.com> wrote:
> frank@openminds.be said the following on 6/30/2004 10:27 AM:
>> Maar t punt is dat als het 777 moet zijn bij dommel, en andere klanten
>> op dezelfde server kunnen cgi's uitvoeren, dat waarschijnlijk wil zeggen
>> dat users in mekaars files kunnen schrijven en zo ...

> Het gaat om gallery (gallery.menalto.com).
> De gallery zelf is mbv htaccess passwd afgeschermd maar dat helpt niet
> veel denk ik.

Helpt niet als je rechtstreeks aan de files kan...

> Misschien is er zoiets als open base dir voor cgi's?

Neen, bestaat niet (deftig). Tenzij ze elke user in een chrooted apache
draaien, maar dan heb je per klant een afzonderlijk ip adres nodig, en
dat mag niet van RIPE

> Geef anders een poc cgi (harmless aub ) en ik probeer het eens uit.

euh, iets eenvoudigs als een directory listing van een gebruiker
opvragen of zo, en checken onder user die cgi wordt uitgevoerd.
Maak bv volgende file als test.cgi (op test.pl), upload het naar een dir
waar je cgi's kan uitvoeren, roep het op in de browser, en kijk wat er
gebeurt:

#!/usr/bin/perl

$dir="/usr/local/psa/home/vhosts/";
$a=`ls -al $dir`;
$b=`id`;
print "Content-Type: text/html\n\n";
print "<html><body><pre>\n";
print "ik ben user: $b\n\n";
print "listing van $dir:\n";
print $a . "\n";
print "</pre></body></html>";

Eventueel kan je $dir =
"/usr/local/psa/home/vhosts/domainvaniemandanders.be/httpdocs/" proberen
....



Vriendelijke groeten,
Frank Louwers

--
!!! Nieuwe formules voor resellers !!!
Openminds bvba www.openminds.be
Tweebruggenstraat 16 - 9000 Gent - Belgium

dj <dj021587_NOSPAM@planetinternet.be> wrote:
> hmmmm... apache/php/cgi-bin zal meestal als nobody draaien, niet als
> root. Dus als je moet schrijven in die files, kan je het vergeten met 700.

Hangt dus af van je security model. Bij ons draaien de php en cgi
scripts onder de rechten van die klant, dus 600 voor datafiles werkt
perfect...

> ik geloof niet dat je dingen kan uitvoeren buiten je toegewezen
> directory...

voor perl/python/... scripts is dat praktisch (bijna) niet te beperken,
tenzij je een hele hoop heel nuttige zaken er ook uithaalt.

> php heeft die vervelende eigenschap om veel te veel te
> tonen zoals full paths enzo.

Er is niks mis met full paths Als je security model afhangt van het
al dan niet weten dat de homedir van user X
/home/servernaampje/accounts/iets_obscuur/X is, ben je verkeerd bezig
imho.


Vriendelijke groeten,
Frank Louwers

--
!!! Nieuwe formules voor resellers !!!
Openminds bvba www.openminds.be
Tweebruggenstraat 16 - 9000 Gent - Belgium

frank@openminds.be said the following on 6/30/2004 12:21 PM:
> Helpt niet als je rechtstreeks aan de files kan...

Parent dir heeft, directory genaamd gallery, heeft 755 als perms en de
hoofddir, httpdocs heeft 750 als perms.
httpdocs: ftp666 / psaserv
alle onderliggende dirs zoals gallery en ablums, ...: ftp666 / psacln

Wordt het zo ook niet tegengehouden?


> Neen, bestaat niet (deftig). Tenzij ze elke user in een chrooted apache
> draaien, maar dan heb je per klant een afzonderlijk ip adres nodig, en
> dat mag niet van RIPE

Chrooted apache weet ik niet van maar afhankelijk van forumule kan je al
of niet over een eigen ip nummer beschikken.
Zie www.dommel.be


> euh, iets eenvoudigs als een directory listing van een gebruiker
> opvragen of zo, en checken onder user die cgi wordt uitgevoerd.
> Maak bv volgende file als test.cgi (op test.pl), upload het naar een dir
> waar je cgi's kan uitvoeren, roep het op in de browser, en kijk wat er
> gebeurt:

Error 500 op het document dat staat in de cgi-bin directory