Bekijk Volledige Versie : SuPHP
Graag zou ik willen weten of iemand ervaring heeft met: suPHP
Hoeronder een quota over het product. Zie voor meer info http://www.suphp.org.
suPHP is a combination of an Apache module (mod_suphp) and an executable which provides a wrapper for PHP. With both together, it is possible to execute PHP scripts with the permissions of their owner without having to place a PHP binary in each user's cgi-bin directory. suPHP doesn't need Apache's suExec, provides a logging function and support for different php.ini's.
Zelf denk ik dat het potentie heeft echter vraag ik mezelf nog altijd af wat het voordeel is van PHP als CGI tegenover CLI. Zit er performance verschil in en andere noemenswaardige verschillen? VErder wat vinden jullie andiger suPHP of PHP dmv SuExec door gebruik te maken van de patch op www.localhost.nl
Voor luie mensen die de install willen volgen: http://www.debianhowto.de/de/suphp/suphp.pdf
StarInternet
01/07/03, 10:14
Onder windows is de module beter.
Na een test van 1200 opvragingen per minuut werdt de cgi versie erg traag en de module versie bleef vrij kalm.
Weet niet hoe dit onder linux zit? heb nooit PHP als cgi versie draaien.
Alleen heb ik een php cgi binary maar die is alleen voor user root.
StarInternet
04/07/03, 16:43
blijft erg stil over dit topic .
Het is wel een belangrijke topic qua veiligheid.
Maar ik denk dat de meeste niet weten wat php suexec en suphp.
Demios als je suexec heb geinstalled kan je dan niet meer met php/perl/cgi in de mappen van andere ?
paulmatthijs
04/07/03, 20:10
wij hebben dit opgelost door alles te chrooten, werkt prima voor php.
Hoe heb je alles gechroot in PHP als ik mag vragen? De open_base_dir restrictie e.d. heeft namelijk nou niet bepaalde de reputatie dat deze on omzeilbaar zijn.
paulmatthijs
05/07/03, 18:05
even aan systeembeheerder gevraagd en die gaf als antwoord 'ldd php.so en open_base_dir wil je niet omzeilen'.
vraag me niet meer, want ik weet het niet :D
Origineel geplaatst door paulmatthijs
even aan systeembeheerder gevraagd en die gaf als antwoord 'ldd php.so en open_base_dir wil je niet omzeilen'.
vraag me niet meer, want ik weet het niet :D
ben ik de enigste die van dit stukje niets snapt ? :huh: :huh: :X
Klinkt als een uitspraak van een tweakers.net nerd die niet weet waar hij het over heeft ;)
Kom zeg, wat lult ie nou over de module van php omzeilen?
Neehoor snap er ook helemaal niets van. Iemand die het wellicht iets zou kunnen verduidelijken??
ik heb zelf gewoon safe_mode on en open_base_dir ingesteld en alles werkt nog prima :) volgens mij heb je verder ook niet echt veel nodig? of zijn er nog tips ?
Hoe doe jij het met bestanden die geupload worden via Apache en die moeten worden verwijderd? Dat kan namelijk niet via FTP moet dan ook weer via Apache. Beetje omslachtig dus (mijn inziens).
Verder is in het verleden meermalen gebleken dat zowel safe_mode als open_base_dir niet consequent waren. Dus daar vertrouw ik niet meer op.
Origineel geplaatst door Deimos
Verder is in het verleden meermalen gebleken dat zowel safe_mode als open_base_dir niet consequent waren. Dus daar vertrouw ik niet meer op.
ow ? how that so?
Zie de bug-traq van PHP. O.a.
http://www.phpbuilder.com/mail/php-developer-list/2002011/1551.php
http://bugs.php.net/bug.php?id=17790
http://www.google.nl/search?hl=nl&lr=&ie=UTF-8&q=+site:bugs.php.net+PHP+safe_mode+bug
Ach, lekker interessant :p PHP in safe mode laten draaien, dat kun je niet maken als betaalde host vind ik. Daar begin ik dus niet aan. Klanten moeten gewoon verantwoord omgaan met de aangeboden ruimte, doen ze dit niet, dan zijn er genoeg logs die hen kunnen identificeren als de veroorzaker van evt. problemen. De vitale delen (passwords, backups etc) kunnen zowieso enkel door de root user ingelezen worden, dus ik zie het probleem überhaubt niet zo..
Dmv programmas als cat e.d. kan je zo achterhalen in welke dirs is geweest en je bent een hele knappe jongen wanneer je alles logt. Dit is namelijk praktische niet te doen. Verder weet ik zeker dat een handige gebruiker op een machine zonder safe_mode veel waardevolle info kan vergaren. Dit kan ook vaak dmv Perl enkel is het dmv PHP veel gemakkelijker.
StarInternet
05/07/03, 21:26
Origineel geplaatst door eXite
Ach, lekker interessant :p PHP in safe mode laten draaien, dat kun je niet maken als betaalde host vind ik. Daar begin ik dus niet aan. Klanten moeten gewoon verantwoord omgaan met de aangeboden ruimte, doen ze dit niet, dan zijn er genoeg logs die hen kunnen identificeren als de veroorzaker van evt. problemen. De vitale delen (passwords, backups etc) kunnen zowieso enkel door de root user ingelezen worden, dus ik zie het probleem überhaubt niet zo..
lekker lullig voor de mensen met een cms of een script van meer dan 1000 euro die jouw users gewoon gratis kunnen downloaden?
Ik raad die mensen altijd een dedicated server aan, zo komt er ook bij mij op de plank wat brood :)
Helaas is dat niet voor iedereen weggelegt. Maar niemand dus ervarin met mod_suphp :S. Naja dan maar zelf eens testen. Lijkt wel of ik de enige ben die hier om de veioligheid mbt PHP inzit :X
Nee hoor je bent niet de enige. Mij is enige tijd geleden aangegeven dat PHP 5.0 voorgoed met dat probleem zou afrekenen, maar de Changelog van de beta bekijkend vind ik er niets over terug. Misschien moet ik me er opnieuw in verdiepen.
Het probleem tot nu toe bij mij is geweest dat ieder alternatief er ook voor zorgde dat er nogal wat veranderingen nodig waren om het werkend te krijgen. Zo wil phpmyadmin standaard niet werken onder php-cgiwrap, dus dat valt voor mij weg. Niet omdat phpmyadmin nou zo belangrijk is, maar ik verwacht gewoon dat het een totale imitatie wordt van mod_php. Een klant die een script download en installeert moet mij dan niet lastig vallen met dit soort problemen.
Dus ik moet eens een keer nalopen of mijn standaard tests (phpmyadmin, phpbb, phpnuke/postnuke) vlekkeloos draaien onder suphp, zonder enige code aan te passen. Dan wordt het pas interessant voor mij.
PHPmyADMIN werkt perfect met Suexec. Enkel moet je dan gebruik maken van Cookies ipv http_auth otie in de config.
het gedoe met http_auth heb ik gelezen, maar er zijn nu eenmaal niet zo heel veel scripts die daar gebruik van maken, dus daar kan ik mee leven. En phpnuke, postnuke, phpbb en een zooi andere forums? En gallery? Als je dat eens zou kunnen bevestigen, gooi ik na mijn vakantie (hehe :) ) suphp erop en laat ik het je weten (als je het tot die tijd nou nog niet weet).
Ik zie neit in waarom bovenstaande programmas niet zouden werken..... Maar ik zal wanneer ik tijd heb eens in mijn Port collectie make install gaan doen :)
StarInternet
08/07/03, 21:21
Origineel geplaatst door Deimos
Ik zie neit in waarom bovenstaande programmas niet zouden werken..... Maar ik zal wanneer ik tijd heb eens in mijn Port collectie make install gaan doen :)
Ik installeer wel mod_suphp.
De mensen met speciale scripts kunnen het bij mijn testen op de testing bak als ze dat willen.
nou ja niets speciaals, gewoon de standaard zooi die de klanten er ook op gooien. Ik ga maar eerst eens op vakantie en als ik terug ben laat ik mijn bevindingen weten.
Deimos, om terug te komen bij jouw vraag waarom ze niet zouden werken, het is heel simpel. Heel vaak is het zo dat de environment anders wordt, en daardoor de globale variabelen (super variables, whatever) daardoor niet hetzelfde zijn als bij mod_php. En daar wil het wel eens fout gaan (heb al 2 verschillende geprobeerd, php-cgiwrap en nog een andere waarvan ik de naam niet meer herinner). Besides, op hun website hebben ze het al over het feit dat http_auth anders gaat, dus ik vermoed dat er wel meer problemen de kop zullen opduiken. Ik hoop het niet, maar de mogelijkheid bestaat.
StarInternet
09/07/03, 03:20
Premature end of script headers: /home/sites/site3/web/index.php
Doe ik wat fout of moet er wat extra in de php files?
Geen idee of je wat fout doet, je geeft ons nu een beetje weinig info.
StarInternet
09/07/03, 10:55
Origineel geplaatst door Deimos
Geen idee of je wat fout doet, je geeft ons nu een beetje weinig info.
Dit is de error in error_log.
Alle .php bestanden zijn nu offline.
-----------------------------------------------
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, admin and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
----------------------------------------
suphp_log
----------------------------------------
[Wed Jul 09 03:25:49 2003] [info] /home/sites/site3/web/index.php executed as user starinternet (1007), group site3 (113)
[Wed Jul 09 03:43:39 2003] [info] /home/sites/site3/web/index.php executed as user starinternet (1007), group site3 (113)
[Wed Jul 09 03:51:22 2003] [info] /home/sites/site3/web/index.php executed as user starinternet (1007), group site3 (113)
[Wed Jul 09 03:51:26 2003] [info] /home/sites/site3/web/index.php executed as user starinternet (1007), group site3 (113)
[Wed Jul 09 10:53:20 2003] [info] /home/sites/site3/web/index.php executed as user starinternet (1007), group site3 (113)
------------------------------------------
Dus dat gaat goed na mijn weten.
Waarom apache nu zo zit te zeuren.
heb je wel de php cgi versie geinstalleerd ipv de cli versie?
StarInternet
09/07/03, 11:22
Origineel geplaatst door Deimos
heb je wel de php cgi versie geinstalleerd ipv de cli versie?
soryr naar de verkeerde php binary laten forwarden =)
StarInternet
09/07/03, 13:18
het werkt nu perfect ook de http header van phpmyadmin.
als iemand een script wil testen geef het dan even door.
wil anders wel test login aanmaken.
StarInternet
09/07/03, 13:42
SCRIPTS / WERKENDE OPTIES
- uploaden werkt en wordt onder de user van de script geplaatst.
- phpinfo zie http://beta.starxs.nl/test.php
- phpmyadmin werkt goed
- normale scripts hierzo werken perfect
- zend encoded scripts werken perfect
-- http://beta.starxs.nl/info.php
- php errors worden in de browser gezet ipv error_log (voordeel)!
BEVEILIGING
- controleert gebruiker (GID onder de 100? geen toegang!)
- start script vanaf de eigenaar
- kan scripts buiten document_root niet openen
- upload de bestanden op de naam van eigenaar
OPTIES
- per virtualhost suphp aan en uit zetten
- per virtualhost suphp een aparte php.ini file geven.
Wat ik me nu afvraag, op het moment dat ik cpanel de boel laat updaten, is dat dan niet allemaal weg en kan ik dus alles opnieuw instellen?
Of vraag ik nu iets heel doms :x :p
StarInternet
09/07/03, 14:59
Origineel geplaatst door eXite
Wat ik me nu afvraag, op het moment dat ik cpanel de boel laat updaten, is dat dan niet allemaal weg en kan ik dus alles opnieuw instellen?
Of vraag ik nu iets heel doms :x :p
legt er aan hoe de update werkt.
Schrijft hij de httpd.conf opnieuw dan heb je een probleem =)
Trouwens het activeren van .php heeft een andere commando.
Dus zou meschien niet werken onder cPanel.
Ik heb zelf geen cPanel dus zou het niet weten.
Stefan Mensink
15/07/03, 17:29
Wat ik vaker heb gezien bij wrapped PHP is dat de apache-specifieke functies niet meer werken.
Bijvoorbeeld een virtual - werkt die nog?
Dus bijv: <?php virtual("/test.html"); ?>
StarInternet
15/07/03, 17:43
Fatal error: Call to undefined function: virtual() in /home/sites/site3/web/test.php on line 1
maar is niet erg handige functie.
Beter include() gebruiken
Hmm nadeel is wel dat die CGI versie rete sloom is ten opzichte van de CLI versie.. ding wordt elke keer het geheugen in geladen terwijl de CLI maar een keertje wordt geladen. Als je dus een druk bezocht doosje hebt gaat je dit aardig wat prestatie kosten ben ik bang..
Ik heb idd ook rumoeren gehoord over het oplossen van dit probleem in PHP5 en ben benieuwd hoe dit gaat uitpakken..
Origineel geplaatst door trancer
Hmm nadeel is wel dat die CGI versie rete sloom is ten opzichte van de CLI versie.. ding wordt elke keer het geheugen in geladen terwijl de CLI maar een keertje wordt geladen. Als je dus een druk bezocht doosje hebt gaat je dit aardig wat prestatie kosten ben ik bang..Waarom vergelijk je het met de CLI versie en niet met de module ;) ? Dat lijkt mij een stuk interessanter. Verder kan je mij inziens beter wat performance verlies hebben dan een minder secured systeem.
Ik heb idd ook rumoeren gehoord over het oplossen van dit probleem in PHP5 en ben benieuwd hoe dit gaat uitpakken.. Dit zou mooi zijn, echter duurt het (denk ik) nog wel een tijdje voor 5.x zal worden gereleased. Tevens vraag ik mij af hoe ze dit denken te kunnen oplossen zonder de module als aparta user te draaien wat niet mogelijk is met Apache 1.3.x. OF zouden ze PHP5 dusdanig goed werkend maken dat iedereen oook direct overgaat op Apache 2?? Dan zouden de problemen inderdaad zijn verholpen.