Onderwerp: Directadmin Permissies Probleem..

Hallo!

Ik zit met een aantal problemen!

Forum software schrijft de bestanden weg onder permissie van Apache i.p.v. mijn eigen account, hierdoor kan ik na aanpassingen via mysql of clean install van de forumsoftware niks meer doen, zowel bekijken als verwijderen. Echter kan dit wel als ik via Direct Admin, de Permissies reset. Ik heb dit uitgeprobeerd met phpbb, vbulletin en invision power board software. Problemen die ik ook tegen kom is met uploaden via php scripts, ze zijn alleen toegankelijk als je ingelogd bent, of zodra ik de permissies via Direct Admin reset, voor iedereen!


Hoe kan ik dit oplossen en waar licht dit aan?

Met vriendelijke groet,

Kevin Tas

Dit is normaal, de webserver met php draait onder de gebruiker apache.

Het is mogelijk dit op verschillende manieren server side op te lossen door php onder de eigen gebruiker te draaien ( suPHP, FastCGI, ... ) of met mod_ruid, mod_suid ...

Installeer PHP in CGI, dan is het probleem opgelost.

En mocht je naar (Fast) CGI gaan, even wat problemen die je tegen gaat komen:

- Chmod geen bestanden hoger dan 755, dan krijg je een 500-page (Internal server error). PHP zal draaien onder de user in plaats van als apache. 755 is de goede waarde voor directory's en 700 voor bestanden. Alles boven de 755 (andere users met schrijfrechten) leidt dus tot een 500-foutmelding.

- http://ip.ip.ip.ip/~user werkt in de meeste gevallen niet meer. Nu is dit toch heel evil met de beveiliging, maar waar het met mod_php nog kon, is het bij PHP als CGI niet meer toegestaan.

- 'php_ini set' dingen in een .htaccess bestand zijn niet meer toegestaan. Eindelijk kunnen users zelf geen aanpassingen meer doen. Wel kun je een hele php.ini delegeren naar een user door deze bijvoorbeeld een niveau onder de public_html te zetten. Wil je dat de user zelf aanpassingen doen (evil!), chown je het bestand naar de user, wil je dat enkel de root dit kan (good!), chown je het bestand op root.

Ook opletten voor het extra RAM gebruik dat dit teweeg brengt (FastCGI) en meer disk i/o bij suPHP (steeds start / stoppen van de php deamon)

En waarom staat er nu bij elk script in de readme, chmod 777 geef je iedereen alle rechte, niet bepaald goed.

Het voordeel is als je php in CGI onder de user draait dat chmoden niet meer nodig is... en je moet je apache niet opnieuw compilen als er een nieuwe PHP versie is

Oorspronkelijk geplaatst door Tim.Bracquez

Het voordeel is als je php in CGI onder de user draait dat chmoden niet meer nodig is... en je moet je apache niet opnieuw compilen als er een nieuwe PHP versie is

Sterker nog, ook niet na een wijziging in de php.ini. Helemaal geweldig

(Fast)CGI is makkelijker te implementeren dan mod_ruid. Niet dat deze slecht is, maar het vereist enkele aanpassingen in de DA templates en je moet al je Webmail/phpMyAdmin links veranderen. (Niet zo slecht, meteen een goede reden om deze eens achter SSL te zetten)

Houdt er even rekening mee dat bepaalde modules niet werken in een CGI omgeving. Ik doel met name op de PHP cachers. Eaccellerator zal bijvoorbeeld niet meer werken en Xcache zal enkel trager worden, zoals ik zelf geconstateerd heb bij Magento.

Oorspronkelijk geplaatst door Randy

Sterker nog, ook niet na een wijziging in de php.ini. Helemaal geweldig

klopt en je php draait niet mee bij het laden van statische pagina's
trouwens een nieuwe directadmin installatie kan nu met suPHP standaard geïnstalleerd worden. Heb wel nog geen upgrade van mod_php door directadmin laten doen op een bestaande installatie(mogelijk met script?), maar dit is niet zo'n groot werk om dit manueel te doen...

Als je custombuild (niet customapache) gebruikt, kun je een mod_php omgeving zo omzetten naar een (Fast)CGI omgeving. Controleer daarna wel de usermappen even op files met rechten hoger dan 755. En je php path gaat anders worden, zeker als je PHP 4, 5 en 6 naast elkaar gaat installeren, wat bij een CGI omgeving geen probleem is.
mocht je het niet aandurven wil ik wel kijken of ik een uurtje vrij kan maken deze week.

Tim: grappige tool trouwens op je website. Die zal ik ook eens op m'n 'nog mee spelen' lijst zetten

Oorspronkelijk geplaatst door Randy

Tim: grappige tool trouwens op je website. Die zal ik ook eens op m'n 'nog mee spelen' lijst zetten

Hehe ja, het is nu nog speelgoed maar toch o zo handig