Bekijk Volledige Versie : PHP draaien als eigenaar van de scripts
Ben bezig om te testen hoe het precies zit met de mogelijkheden om php als de eigenaar van een script te draaien met PHP en Apache 1.3.27. Maar heb om eerlijk te zijn nog geen handige methode gevonden. Zo moet er bij de cgi versie namelijk boven elk PHP script #!/usr/bin/php worden gezet, netzoals het geval is met Perl scripts.
Toch lijkt het mij, dat het anders (makkelijker voor klanten, dus zonder #!/usr/bin/php) moet kunnen. De vraag is echter hoe, uiteraard voor apache 1.3.* Aangezien apache 2 nog net stabiel genoeg is icm andere modules.
Daarvoor is voor bij Apache 2 een Apache module 'perchild' in de maak. Deze laat volgens verwachting echter nog enkele maanden op zich wachten.
Apache 2 draait op zich wel, en icm deze module ook zelfs nog wel, maar vraag niet hoe :D
Voor zover ik weet wordt een dergelijke module niet gemaakt voor de Apache 1.3.*, het blijft dus nog ff wachten op de stabiele Apache 2.
Stefan Mensink
14/04/03, 12:53
Een bekend probleem zeg! Natuurlijk zijn er wel meer mogelijkheden om wat beveiliging te doen, maar met virtual hosting wil je natuurlijk niet hebben dat klanten in elkaars files kunnen kijken (en dan met name aan dbvars.inc-achtige zaken).
Een tijdje terug heb ik hiervoor sbox (Op http://stein.cshl.org/WWW/software/sbox/ te downloaden) gepakt en er een aantal aanpassingen voor gemaakt. Effectief is het script nu een suid-wrapper die de scripts uitvoert onder het account van de eigenaar van het script. Klein nadeeltje is dus wel dat de apache-specifieke PHP-functies komen te vervallen.
Momenteel ben ik het script aan het testen met een aantal gebruikers. Het lijkt vrij goed te gaan maar het vereist nog wat intensieve tests vind ik.
Indien er interesse is hierin dan hoor ik dat wel.
PS: ja, ook ik wacht met smart op het moment dat apache 2 en php echt stabiel zijn.
Met apache specifieke functies bedoel je neem ik aan de $_ENV* variabelen en de $_SERVER vars? Zou wel jammer zijn, maar als dat noodzakelijk is is het niet anders.
Stefan Mensink
14/04/03, 13:07
Tja, dat is de consequentie als je afstapt van mod_php en de php's gaat draaien via cgi.
Ik heb nu wel iets handigs gevonden suexec patches voor Apache. :) Installatie was wel wat lastig, maar kan ook komen omdat ik telkens een stap verkeerd deed :X.
Naja het werkt in ieder geval naar behoren, zoals het nu lijkt. Enige nadeel is, dat ik apache met de hand heb moeten compilen in plaats van met behulp van ports. (ja ik ben een luie sysadmin ;))
[edit]
Url vergeten naar de patches: http://www.localhost.nl/patches/
Hou ook cgiwrap (http://cgiwrap.unixtools.org/) in de gaten. Toen ik laatst hun cvs versie uitprobeerde kon je daar ook php mee wrappen, zonder in elke script #!/usr/bin/php op de eerste regel te plaatsen. Ik raad alleen niet aan om een cvs versie op een productieserver te gebruiken :)
Origineel geplaatst door Qweb-Yavuz
Hou ook cgiwrap (http://cgiwrap.unixtools.org/) in de gaten. Toen ik laatst hun cvs versie uitprobeerde kon je daar ook php mee wrappen, zonder in elke script #!/usr/bin/php op de eerste regel te plaatsen. Ik raad alleen niet aan om een cvs versie op een productieserver te gebruiken :) Je zult wel moeten wil je die functionaliteit gebruiken aangezien het project voor zover ik heb kunnen zien dood is. verder heb ik het niet aan de praat kunnen krijgen dus ben ik overgestapt op phpsuexec. Werkt wel lekker alleen irri dat ik nu in apache error log moet kijken voor debug info :). Maar alles went :).