Apache met php als cgi module en suexec

Pagina: 1
Acties:

  • kneus
  • Registratie: November 2000
  • Laatst online: 26-02-2025
Hoi,

Ik hoop dat ik hier in het juiste stukje van het forum zit.

Ik heb het volgende probleem. Ik draai een apache server onder debian, en wil php en cgi draaien. Uiteraard geen probleem. Alleen het moet wel veilig, en dus scrips onder de eigen gebruikersnaam laten draaien.

Hiervoor heb ik gekozen voor suexec. Voor cgi uiteraad prima, maar voor php erg vervelend, nu moet er namelijk boven ieder script #!/usr/bin/php4 zetten. Op zich ook nog geen probleem als dit noodzakelijk is, maar het werkt niet echt lekker. Als het script van buitenaf aangeroepen wordt, dan moet het er wel boven, maar als het geinclude wordt niet, dan gaat hij over zijn nek. Niet echt werkzaam zo.

Ik heb een hele tijd geprobeerd met suexec en met cgiwrapper, maar het wil niet lukken. Ik wil het liefst gewoon suexec gebruiken, maar het wil niet lukken, steeds weer andere problemen. Ik heb de httpd.conf nu zo staan:

ScriptAlias /php/ "/usr/bin/"
AddType application/x-httpd-php .php
Action application/x-httpd-php "/php/php4"

maar ik krijg nu deze error:
Parse error: parse error in /usr/bin/php4 on line 286

Ik heb met debian stable de volgende pakketten geinstalleerd: php4-cgi, apache, apache-mod-perl

Iemand die me kan helpen, een tip kan geven, of mij kan vertellen hoe jullie dit hebben opgelost?

Casper

  • sebas
  • Registratie: April 2000
  • Laatst online: 16-12-2025
Waarom gebruik je niet mod_php? Dit is voor webscripting icm. apache zelfs nog duidelijk sneller. Immers draai je ook mod_perl, terwijl perl eigenlijk vaker als cgi gebruikt wordt dan php.

Everyone complains of his memory, no one of his judgement.


  • kneus
  • Registratie: November 2000
  • Laatst online: 26-02-2025
Omdat de scripts allemaal onder de eigen gebruikersnamen moeten draaien, en met mod_php is dat onmogelijk. Daarmee draait alles onder de gebruikersnaam van Apache.

  • blender
  • Registratie: Juni 2001
  • Niet online
Wat is dan de reden dat de scripts onder de eigen gebruikersnaam moeten draaien?
Ik neem aan dat je Apache zelf ook hebt draaien met een eigen user en group met weinig permissies? Dan kan er toch vrij weinig mis gaan lijkt me...

Misschien dat Apache zelfs nog chrooted kan draaien maar daar heb ik zelf geen ervaring mee.

  • kneus
  • Registratie: November 2000
  • Laatst online: 26-02-2025
Het probleem is, dat als iedereen scripts onder dezelfde rechten kan draaien, je ook scripts kan draaien die scripts van anderen uitlezen, en zo kun je bijvoorbeeld mysql wachtwoorden uitlezen en dat is niet de bedoeling. Vandaar dat het onder eigen gebruikersnamen moet draaien.

Verwijderd

Toch fijn om te horen dat er ook mensen zijn die begrijpen dat mod_php (zeker in combinatie met gebruik van MySQL) op shared hosting simpelweg onveilig is :)

Zelf ben ik er niet zo in thuis, omdat ik hier een heel andere oplossing voor bedacht heb, maar heb je al gekeken naar safe_mode ? Het geeft soms wat problemen met het uploaden van files via http, maar over het algemeen is het wel te doen. Weet alleen niet 100% zeker of dat ook beschermt tegen het lezen van andermans files als dat gedaan wordt via een extern programma dat weer vanuit 'n php script wordt aangeroepen. bijvoorbeeld via system()... maar dat zou je eens moeten proberen :)

  • kneus
  • Registratie: November 2000
  • Laatst online: 26-02-2025
Zover ik het begrepen heb uit de manuals, is de safe mode een bescherming voor het systeem, en zorgt dat ze niet overal in het filesystem kunnen enzo maar niet tegen het accessen van elkaars scripts.

ScriptAlias /php/ "/usr/bin/"
AddType text/html .php .php3 .phtml
AddHandler php-script php php3 phtml
Action php-script /php/php.cgi

ik ben het nu wat eenvoudiger aan het proberen, maar helaas, nu krijg ik zoŽn normale cgi fout. en in de de error log:

php.cgi: error in loading shared libraries: libmcrypt.so.4: cannot open shared object file: No such file or directory

Ik heb het gevoel dat ik wel wat verder kom. Ik kan alleen nu weer niet vinden in welk debian pakket ik libmcrypt heb zitten... had ik ooit wel dacht ik toch...

Verwijderd

een .php script dat eigendom is van user X kan tijdens het draaien NIET aan bestanden komen die niet ook eigendom van user X zijn. Maar ik weet dus niet hoe het zit als er vanuit dat php script via system() een programma gestart wordt :)

Verwijderd

Overigens, .phtml is toch van perl en niet van php ?
Pagina: 1