[php] Safemode restricties omzeilen

[Mexxus]

Beste mensen,

Sinds kort host ik m'n website bij een hosting waarbij de Safe Mode aan staat. Jep, het is een betaalde hostingprovider. Bij het installeren van een fotoboek script kom ik in de knoei met deze safemode, o.a. bij functies als mkdir(), open_dir() en move_uploaded_file().

Ik heb een folder:
../public/fotoboek

In die folder wil ik via web-based forms nieuwe folders (albums) kunnen aanmaken, waarin vervolgens ook weer web-based foto's geupload kunnen worden.

Bij zowat elke handeling verschijnen er warnings van "SAFE MODE restriction" als:

Warning: opendir() [function.opendir]: SAFE MODE Restriction in effect. The script whose uid is 1096 is not allowed to access public/fotoboek/1082557569 owned by uid 33 in /HTML/fotoboek.php on line 260

Hier op GoT heb ik een aantal topics doorgespit, maar daaruit kon ik alleenmaar opmaken dat deze functies dankzij Safe Mode gewoon niet werken:

[PHP] Safe_Mode & mkDir();
[PHP] [php]opendir
[PHP] [PHP]Upload problemen in safemode *

Op php.net is het volgende te lezen over move_uploaded_file():

Opmerking: Als safe-mode aan staat, zal PHP kijken of de bestanden of directories waarmee je wilt werken dezelfde UID heeft als het script dat wordt uitgevoerd.

Opmerking: move_uploaded_file() heeft geen last van normale safe mode UID-beperkingen. Dit is niet onveilig, omdat move_uploaded_file() alleen werkt op bestanden die zijn geupload met PHP.

Ik upload de files via php, en toch mogen ze niet verwerkt worden met move_uploaded_file(). php zeurt inderdaad om de UID, maar ik heb geen idee hoe dat te fixen.

Als antwoord op een mailtje van me naar de hosting, vertelde ze mij dat de functies 100% zeker wel mogelijk zijn in Safe Mode, mits de folders de juiste rechten (chmod) en de juiste owner (chown) hebben.

Ik ben druk bezig geweest met chmod(). echter, het lijkt me niet slim de boel op 777 te zetten, en tevens werkt chmod() in php ook niet. De enige manier om chmod() uit te voeren is dus via FTP. Dan zou ik dus alsnog voor elk nieuw aangemaakt album opnieuw via FTP de chmod rechten moeten geven.

Zelfde geld voor chown(), dat werkt ook niet via php zelf. In PuTTY heb ik al geprobeerd chown uit te voeren, maar daarbij krijg ik "Not permitted" meldingen. De hosting heeft dus de folder "public/fotoboek" naar de owner www-data ge-chowned, maar dat heeft verder geen effect op de meldingen, die zijn er nog steeds.

Kort samengevat:
Safe Mode staat aan. Veel php functies werken daardoor niet. chmod() werkt enkel via FTP, chown() lukt me helemaal niet. Folders moeten webbased aangemaakt kunnen worden, waarin vervolgens files geupload kunnen worden. Ik krijg het niet voor elkaar. De hosting is er zeker van dat het mogelijk is met de juiste rechten en owners, maar kan me verders niet helpen.

Zijn er hier mensen die duidelijkheid kunnen scheppen? Kan het nou wel, zoals de hosting zegt, of kan het nou niet, zoals ik zelf ervaar? Als het wel kan, op welke manier dan? Ik ben na 3 dagen klooien zo'nbeetje ten einde raad...

Ohja, de server details:
Apache/2.0.45 (Unix) mod_ssl/2.0.45 OpenSSL/0.9.6c PHP/4.3.1

[ripexx]

waarschijnlijk zit het probleem in een rechten conflict. Zoals je zelf al hebt aan gegeven is de directory owner anders dan de uitvoerder van het script. Dit is de user die apache gebruikt. Wat je eventueel nog kan proberen is om de groep rechten goed te zetten maar dat werkt alleen als de groepen van apache en de directory's gelijk zijn. Verder kan je je hostermailen en vragen wat er oa aan gedaan kan worden met de unix rechten set.

[pietje63]

Als php niet de eigenaar van de directorie is en je wilt er toch in kunnen uploaden dan zal je hem toch echt op 777 moeten zetten.
Dit is niet zo heel onveilig hoor.
Verder vind ik het aar dat een hosting provider safe mode aan heeft staan want dat heeft wel meer beperkingen; ze kunnen beter op een andere manier hun servers beveiligen.

[djluc]

pietje63 schreef op 21 april 2004 @ 23:35:Verder vind ik het aar dat een hosting provider safe mode aan heeft staan want dat heeft wel meer beperkingen; ze kunnen beter op een andere manier hun servers beveiligen.

Aardig offtopic hier maar het is zeker voor de wat minder kwalitatieve scripters echt wel belangrijk zodat ze geen eenvoudige fouten kunnen maken waarmee ze de servers open kunnen zetten.

Ik vind het toch echt vreemd dat er nog steeds niet een echt goede oplossing voor dit probleem is. Ik heb niet heel veel UNIX kennis maar: is het niet mogelijk om een map over te dragen aan een andere user? Lijkt mij vreemd als dit zou kunnen maar het zou wel het probleem oplossen.

[sjokki]

Op [rml][ PHP]SAFE_MODE[/rml] heb ik geprobeerd om de oorzaak van dit probleem duidelijk te maken en heb ik ook een aantal oplossingen gegeven. De oplossing met de prefixes wordt onder andere gebruikt in Smarty.

Op oude unixsystemen was het wel mogelijk om je eigen bestanden/directories met chown aan een andere user te geven. Op Linux kan alleen de superuser dat doen.

Chmod werkt perfect, ook onder safemode. Maar je kan het (natuurlijk) alleen gebruiken op bestanden en directories die hetzelfde UID hebben als de uitvoerder van het script.

[Verwijderd]

pietje63 schreef op 21 april 2004 @ 23:35:
Als php niet de eigenaar van de directorie is en je wilt er toch in kunnen uploaden dan zal je hem toch echt op 777 moeten zetten.
Dit is niet zo heel onveilig hoor.
Verder vind ik het aar dat een hosting provider safe mode aan heeft staan want dat heeft wel meer beperkingen; ze kunnen beter op een andere manier hun servers beveiligen.

Zoals? Het probleem met PHP scripts is dat de apache of nobody user (waaronder je script draait) altijd read access moet hebben op alle PHP scripts. Eventuele (DB) passwords in die PHP scripts zijn dus altijd leesbaar voor alle andere scripts.

Safe mode is daar naar mijn weten de enige oplossing voor (tenzij jij natuurlijk een beter idee hebt). Safe mode is ter bescherming van jezelf en niet ter bescherming van de provider...

Zijn er providers die safe mode uit hebben staan? Hoe voorkomen die dan dat je andermans scripts gaat lezen met een eenvoudige fopen() call?

X.

[Gerco]

Er is een oplossing voor dat probleem in de vorm van een apache setting die een cgi binary zal executen als de user die eigenaar is van dat bestand. Als je nu PHP als cgi-binary installeert kost het helaas wel performance, maar heb je dus geen last van dit geneuzel en je kunt safemode uitgooien.

Het beperken van de fopen() kan gewoon met open_basedir natuurlijk. Helaas zat/zit er een hinderlijke bug in apache of php die dat per virtualhost erg irritant maakte omdat de restricties soms overliepen naar andere vhosts. Helaas kun je dan met een eenvoudige exec("cat /etc/passwd"); weer omzeilen. Dit kun je oplossen door alle system commands te blokkeren, maar dat vind ik ook niet zo'n mooi plan.

Dit is helaas niet van toepassing aangezien je die server niet zelf beheert, echter op php.net is het volgende te vinden:

When safe_mode is on, PHP checks to see if the owner of the current script matches the owner of the file to be operated on by a file function.

Dit betekent dat het niet gaat om die het script uitvoert, maar om wie de eigenaar ervan is. Wat je dus zou moeten doen is alle directories (laten) chownen naar jezelf en de webserver schrijfrechten geven op die directories (777).

Het enige probleem wat nu overblijft is dat zodra de webserver een bestand ge-upload heeft naar de fotoboek directory, het eigendom is van de webserver en andere scripts dus niets meer kunnen met die file vanwege de safe mode restricties (UID van je script <> UID van de file). Hiervoor zou uik niet zo vlug een oplossing weten.

Voor zover ik weet is het enige wat compleet werkt en veilig is de php-suid oplossing, helaas kost dat performance, ik weet alleen niet hoeveel.

[ Voor 14% gewijzigd door Gerco op 22-04-2004 08:07 ]

[sjokki]

Gerco schreef op 22 april 2004 @ 08:05:
Er is een oplossing voor dat probleem in de vorm van een apache setting die een cgi binary zal executen als de user die eigenaar is van dat bestand. Als je nu PHP als cgi-binary installeert kost het helaas wel performance, maar heb je dus geen last van dit geneuzel en je kunt safemode uitgooien.

Je bedoelt suEXEC. Met FastCGI valt het snelheidsverlies nog mee. Maar CGI heeft net zo goed nadelen, zo kan je bijvoorbeeld niet meer de ini-instellingen van PHP veranderen in .htaccess.

Kort geleden is hierover nog een discussie geweest op PHP-dev, zie: deze thread (vanaf post 14 wordt het interessant). En lang geleden deze thread.

[igmar]

sjokki schreef op 22 april 2004 @ 08:41:
Je bedoelt suEXEC. Met FastCGI valt het snelheidsverlies nog mee. Maar CGI heeft net zo goed nadelen, zo kan je bijvoorbeeld niet meer de ini-instellingen van PHP veranderen in .htaccess.

't is maar wat je verstaat onder 'valt mee' . fork() + exec() is een vrij dure operatie. Om van dit hele gedoe ik een keer af te zijn :

mod_suid

[sjokki]

igmar schreef op 22 april 2004 @ 11:30:
[...]


't is maar wat je verstaat onder 'valt mee' . fork() + exec() is een vrij dure operatie. Om van dit hele gedoe ik een keer af te zijn :

mod_suid

Maar forken was toch juist wat FastCGI niet doet? Tenminste dat begrijp ik uit het verhaal op http://www.fastcgi.com/de...i-prog-guide/ch1intro.htm .

[igmar]

sjokki schreef op 22 april 2004 @ 12:22:
Maar forken was toch juist wat FastCGI niet doet? Tenminste dat begrijp ik uit het verhaal op http://www.fastcgi.com/de...i-prog-guide/ch1intro.htm .

fast-cgi vereist speciale cgi-bin apps, en werkt niet met suid programma's.

[Mexxus]

Ik heb inmiddels bijna alle warnings weg weten te werken d.m.v. chmod 777, maar dan toch nog blijft de move_uploaded_file() zeuren dat ´t niet mag omdat de owners anders zijn. Best balen, want ik kan ´t nergens veranderen. Nergens kan ik een chown() uitvoeren...

Dan nog klopt ´t niet, want alles is gewoon via php gemaakt. De folders waarin geupload wordt is ook aangemaakt door php, de file´s worden in die folder vervolgens ook via php geupload, dus zowel de doelfolder als de te uploade file hebben toch de zelfde owner? Dan lijkt ´t probleem volgens mij te liggen bij de file "waarmee" de file geupload wordt, die heb ik namelijk wel zelf via FTP geupload... Anyway, zou ´t opgelost zijn als ik die file door de host effe laat chownen naar de php owner?...

[Infinitive]

Iets wat ik nog niet geprobeerd heb, maar wat misschien(?) kan werken:

kan je shell commando's uitvoeren vanuit php via bij voorbeeld system() of popen()? Dan kan je misschien daarmee de benodigde move, copy en weet ik veel wat nog meer operaties doen...