PDA

Bekijk Volledige Versie : chmodd 777 blokkeren voor users



eweps
01/12/06, 17:21
Beste mensen,

Bestaat er software voor een linux/apache/directadmin bak waarmee ik users kan blokkeren om bestanden en mappen de rechten 0777 te geven?

Alvast bedankt!

dreamhost_nl
01/12/06, 21:05
Installeer phpsuexec. Als je gebruikers de rechten van hun scripts dan op 777 zetten, krijgen ze een "500 Internal Server" melding... :)

eweps
03/12/06, 13:03
Bedankt, dat ga ik eens opzoeken.

SebastiaanStok
04/12/06, 21:04
Perfomance warning!
suPHP heeft een grote perfomance impact :(

Dillard
05/12/06, 00:53
Veel scripts hebben overigens mappen nodig met deze rechten (cache, images, logs etc). Vaak kun je daar wel omheen, maar de doorsnee gebruiker (die braaf de meegeleverde how-to volgt) zal dit niet zelf weten uit te vogelen en de weg naar je support-desk weten te vinden :)

eweps
05/12/06, 01:04
Oke iemand die een andere oplossing heeft?

(Wat ik aan het bericht van Rollerscapes begrijp is dat phpsuexec net zoiets is als mod_suid, wat ook performance vreet..)

wonko
05/12/06, 09:14
als je performance over hebt, is suphp zeker een mogelijkheid. De impact is niet zo dramatisch, en je hebt het voordeel dat je per proces perfect ziet wie de gebruiker is... handig bij slecht gescripte sites...

eweps
05/12/06, 13:01
Is suPHP net zoiets als mod_suid dan? Want dat doet toch hetzelfde?

SebastiaanStok
05/12/06, 13:06
Klopt, alleen doet suPHP een compleet apart proces starten en werkt hij via een CGI manier.

Ik heb het zelf ook gebruikt, en elke keer als ik een script uitvoerde al was een simpele pagina elke keer sloeg de load om hoog.
En plaatjes bewerken, zoals een captcha? de load schoot om hoog het duurde te lang.

Echt ik ben blij dat ik er vanaf ben.
Ik gebruik nu mod_ruid en daar zeer tevreden over :)
Zie ook: http://www.webhostingtalk.nl/scripting-techniek-beveiliging/103250-mod_suid-2-mod_ruid-ervaringen-en-tips-new-post.html

dreamhost_nl
05/12/06, 21:36
Klopt, alleen doet suPHP een compleet apart proces starten en werkt hij via een CGI manier.

Ik heb het zelf ook gebruikt, en elke keer als ik een script uitvoerde al was een simpele pagina elke keer sloeg de load om hoog.
En plaatjes bewerken, zoals een captcha? de load schoot om hoog het duurde te lang.

Echt ik ben blij dat ik er vanaf ben.
Ik gebruik nu mod_ruid en daar zeer tevreden over :)
Zie ook: http://www.webhostingtalk.nl/scripting-techniek-beveiliging/103250-mod_suid-2-mod_ruid-ervaringen-en-tips-new-post.html

PHPsuExec wordt hier gebruikt op al onze cPanel servers en hebben hier nog nooit performance problemen mee gehad. Misschien dat iets elkaar beet in je configuratie?

eweps
06/12/06, 00:18
Hm, mod ruid is op dit moment voor ons nog te weinig duidelijkheid over.. weinig informatie te vinden op internet.. dus misschien is phpsuexec een goede tijdelijke oplossing.

Greenpower
06/12/06, 02:13
Wij draaien suPHP al jaren, shared servers met zo'n 150-200 klanten erop, load komt niet boven 1.00, dus dat het zo funest is voor de performance is onzin.

host3000
06/12/06, 02:30
Ik zie dat suPHP en phpSUexec door elkaar gebruikt worden. Volgens mij zijn het toch twee verschillende dingen.

Wij gebruiken phpSUexec al een paar jaar op de shared hostingservers. Ik merk geen groot performance verschil. Misschien als je de server vol gooit tot het randje, je een probleem erbij hebt. Maar dat lijkt mij in elk geval niet verstandig.

Easewood
06/12/06, 10:03
Performance ligt niet enkel aan de hoeveelheid klanten op een server maar ook aan de configuratie van de machine, de andere services die erop draaien, hoe zwaar de site(s) zijn en hoeveel ze bezocht worden. Het is dan ook redelijk naief te claimen dat het 'onzin' is - je kunt geen appels met peren vergelijken.

Dat suPHP een performance issue heeft door haar CGI opbouw is een feit.
Of dat acceptabel is is een tweede. Dat kan je alleen testen door het in te zetten.

Overigens is het voorkomen van 777 permissies best okay, maar het helpt niet tegen brakke scripting. De meeste attacks zijn remote via http en dan draaien de attacks dus onder de lokale gebruiker (al dan niet suPHP). Het enige wat je voorkomt is dat men cross-domain (dus in andere home dirs) aan de slag kan - de attack zelf zal nog steeds succesvol zijn.
Het helpt dus wel maar is geen oplossing.

host3000
06/12/06, 10:32
Performance ligt niet enkel aan de hoeveelheid klanten op een server maar ook aan de configuratie van de machine, de andere services die erop draaien, hoe zwaar de site(s) zijn en hoeveel ze bezocht worden. Het is dan ook redelijk naief te claimen dat het 'onzin' is - je kunt geen appels met peren vergelijken.

Dat suPHP een performance issue heeft door haar CGI opbouw is een feit.
Of dat acceptabel is is een tweede. Dat kan je alleen testen door het in te zetten.


Dat is dus precies wat ik schrijf: een combinatie met de belasting zonder phpSUexec ;)

De onzin verwijzing zal op iemand anders slaan (want dat heb ik nooit geschreven)?

Easewood
06/12/06, 11:44
Klopt. Er is maar een post in deze thread die stelt dat het 'onzin' is...?

wonko
06/12/06, 11:49
Heren, we wijken af, graag ontopic.

eweps
06/12/06, 19:34
Er zijn toch veel mensen die het dus blijkbaar wel gebruiken dat phpsuexec, dus laat ik dat toch maar gaan doen.. overstappen naar mod_ruid kan dan altijd nog zodra er meer informatie over te vinden is(want nu zegt google er weinig over)

Bedankt tot zo ver, mocht iemand nog aanvullingen hebben: graag!