Bekijk Volledige Versie : 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 :)
frank@openminds.be
29/06/04, 23:35
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 :p
frank@openminds.be
30/06/04, 10:35
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
frank@openminds.be
30/06/04, 12:15
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
frank@openminds.be
30/06/04, 12:35
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
frank@openminds.be
30/06/04, 12:35
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
frank@openminds.be
30/06/04, 15:05
Johan V. <johanverstr@msn.com> wrote:
> Error 500 op het document dat staat in de cgi-bin directory
huh?
probeer het script eens te chmodden naar 755 en probeer extenties .cgi
of .pl...
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 2:58 PM:
> probeer het script eens te chmodden naar 755 en probeer extenties .cgi
> of .pl...
whoops, execute bit vergeten...
perms op directory's drwxr-xr-x root/root
paswoorden inlezen gaat prolly wel, dirs verwijderen niet?
frank@openminds.be
30/06/04, 21:25
Johan V. <johanverstr@msn.com> wrote:
> frank@openminds.be said the following on 6/30/2004 2:58 PM:
>> probeer het script eens te chmodden naar 755 en probeer extenties .cgi
>> of .pl...
> whoops, execute bit vergeten...
> perms op directory's drwxr-xr-x root/root
> paswoorden inlezen gaat prolly wel, dirs verwijderen niet?
als welke userid wordt het uitgevoerd? Los daarvan kan je dus schrijven
in elke file/dir die op 777 staat :)
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 9:14 PM:
> als welke userid wordt het uitgevoerd? Los daarvan kan je dus schrijven
> in elke file/dir die op 777 staat :)
Gebruiker ftp666
frank@openminds.be wrote:
> 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).
Inderdaad. Je hebt +x nodig om in die map te kunnen gaan, en dus lezen.
J.
--
Dressing up as a Goth doesn't mean you really are one...
On Tue, 29 Jun 2004 21:09:30 GMT, "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/
755 is meer dan voldoende voor de dir albums en alle onderliggende.
Zorg dat de apache user en group owner zijn.
--
ColdRain
frank@openminds.be
02/07/04, 17:15
JanC <usenet_spam@janc.invalid> wrote:
> frank@openminds.be schreef:
>>> 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 :)
> Je hebt daarvoor niet noodzakelijk per klant een afzonderlijk (publiek) IP
> nodig. Je kan ze allemaal op een verschillende poort draaien en er een
> soort proxy voorhangen op poort 80 die weet welke hostname(s) bij welke
> chrooted apache horen...
strikt gezien true :) maar ken je iemand die dat doet? :)
Vriendelijke groeten,
Frank Louwers
--
!!! Nieuwe formules voor resellers !!!
Openminds bvba www.openminds.be
Tweebruggenstraat 16 - 9000 Gent - Belgium
frank@openminds.be schreef:
>> Je hebt daarvoor niet noodzakelijk per klant een afzonderlijk
>> (publiek) IP nodig. Je kan ze allemaal op een verschillende poort
>> draaien en er een soort proxy voorhangen op poort 80 die weet welke
>> hostname(s) bij welke chrooted apache horen...
>
> strikt gezien true :) maar ken je iemand die dat doet? :)
Da's min of meer de standaard config voor sommige Zope hosters; uiteraard
met Zope voor de backend servers en bijvoorbeeld Apache of zo als front
server, die dan vaak tegelijk ook als static content server (images e.d.)
gebruikt wordt.
Een gelijkaardige techniek wordt ook gebruikt bij FastCGI en zo.
--
JanC
"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9