PHP-Script soll befehl ausführen über User www-data

[globalplayer]

Ich versuche über ein PHP-Script einen CSS-Gameserver zum laufen zu bringen. Ich habe mir Debian auf einer Virtuellen Maschine installiert, sowie einen apache2 , css-server, screen und sudo.

Der Apache-user "www-data" soll über den Benutzer "server3" das Start-Script des Servers ausführen.
(CSS-Server und Start-Script liegen in /home/server3/. Server3 hat bei allen nötigen Dateien das Recht sie auszuführen.)

Ich habe erstmal /etc/sudoers konfiguriert:

www-data ALL=(server3) NOPASSWD: /home/server3/start
www-data ALL=(server3) NOPASSWD: /home/server3/stop
www-data ALL=(server3) NOPASSWD: /home/server3/restart
www-data ALL=(server3) NOPASSWD: /usr/bin/screen

Um das erstmal an der Shell zu testen habe ich folgendes probiert:

also Root:

su www-data

Dann als www-data:

sudo -u server3 /home/server3/start

Dann kommt die Meldung des Start-Scripts "Starting CSS Server #2", was auch so sein sollte.
Aber der server läuft trozdem nicht, lässt sich nicht anpingen.
Auch mit "sudo -u server3 screen -ls" sehe ich keine screen-sitzung des Gameservers.

ABER:
Wenn ich vorher das Verzeichnis wechsle und dann den Befehl eingebe:

cd /home/server3/ 
sudo -u server3 ./start

Dann startet der CSS-Server, lässt sich anpingen und screen Sitzung ist auch da.

Also dachte ich mir ich probiere es im PHP-Script so aus:

$cd = system('cd /home/server3/'); 

$pwd = system('pwd');
	
$sudo = system('sudo -u server3 ./start', $sudoretval);

$checkstatus = system('sudo -u server3 screen -ls', $retvalstatus);

Allerdings scheitert es hier schon beim Verzeichnis wechseln.
Die variable $pwd gibt mir aus: /var/www
Ich kann also das Verzeichnis über das PHP-Script nicht wechseln, in der Shell aber schon.
$sudoretval gibt mir eine 1 aus, $retvalstatus gibt mir "No Sockets found in /var/run/screen/S-server3" aus.

Um es zum laufen zu bringen müsste ich es also schaffen per PHP das Verzeichnis zu wechseln, oder über den befehl mit kompletter Pfadangabe den Server zu starten.

Am meisten würde mich interessieren warum der Server mit der kompletten Pfadangabe nicht startet. Anfängerfehler? Würde zu mir passen...
Denn am liebsten würde ich diesen Weg nehmen.


Das Start-Script sieht so aus:

#!/bin/sh
IP="192.168.178.26"
PORT="27025"
MAP="de_dust2"
GAME="cstrike"
SLOTS="24"
RCON="testpw"
FPS="66.7"

# CSS
echo "Starting CSS Server #2"

sleep 1

screen -A -m -d -S css-server ./css/srcds_run -game $GAME +map $MAP -maxplayers $SLOTS -ip $IP -port $PORT +rcon_password "$RCON" +fps_max $FPS

Noch ein paar infos zum System:

Apache version 2.2.16 (Debian)
Linux Debian 2.6.32-5-686
PHP Version 5.3.3-7+squeeze14

Vielen Dank schonmal!
Gruß,
Patrick

 

[wstuermer]

Das Start-Script sieht so aus:

#!/bin/sh
IP="192.168.178.26"
PORT="27025"
MAP="de_dust2"
GAME="cstrike"
SLOTS="24"
RCON="testpw"
FPS="66.7"

# CSS
echo "Starting CSS Server #2"

sleep 1

screen -A -m -d -S css-server ./css/srcds_run -game $GAME +map $MAP -maxplayers $SLOTS -ip $IP -port $PORT +rcon_password "$RCON" +fps_max $FPS

Da liegt der Hund begraben. Ersetze "./css/srcds_run" durch den vollen Pfad zum Binary - also "/home/server3/css/srcds_run".

 

[d4f]

PHP mit shell_exec UND sudo-Rechten aus zu statten ist sehr riskant.
Du solltest entweder einen Cronjob ausführen lassen welcher periodisch (zB jede Minute) nach neuen Arbeiten in der Datenbank sucht und diese ausführt oder mittels Xinetd das PHP-Skript im Backend durch eine TCP-Verbinung an einen vordefinierten Port anstubsen.

 

[schnoog]

Solange Usereingaben nicht in den shell_exec Aufrufen landen siehe ich (in meiner jugendlichen Naivität) kein Problem.

@TS:

Du kannst mehrere Befehle hintereinander packen

$sudo = system('cd /home/server3/; sudo -u server3 ./start', $sudoretval);

AFAIK wird jeder Aufruf von system im Verzeichnis des Skriptes ausgeführt.

Dieser Code verdeutlicht es:

<?php

$ext=system("pwd");
echo "Startverzeichnis $ext <hr>";
$ext=system("cd /home/server3/");
echo "Wechsel ins Zielverzeichnis: $ext <hr>";
$ext=system("pwd");
echo "Aufruf von pwd in nachfolgenden system Aufruf: $ext <hr>";
$ext=system("cd /home/server3/;pwd");
echo "Aufruf von pwd in selbem system Aufruf $ext <hr>";


?>

Erst der Aufruf von "cd /home/server3/;pwd" sorgt dafür, dass pwd noch im Zielverzeichnis von cd ausgeführt wird

 

[d4f]

Solange Usereingaben nicht in den shell_exec Aufrufen landen siehe ich (in meiner jugendlichen Naivität) kein Problem.

Theoretisch. Praktisch sind aber bei einem Webserver die PHP-Skripte (fast) das einzige Sicherheitsloch. Zumal viele Programme oder Überbleibsel nicht sauber aktualisiert werden oder (noch) unbekannte Lücken enthalten, respektiv bei Eigenentwicklungen oft nicht genug auf Sicherheit geachtet wird.
Sobald der Angreifer dann entweder die Kontrolle über das Skript übernommen hat oder gar ein eigenes hochgeladen hat, hat er direkt eine sehr tiefgehende Kontrolle über das System da er beliebige Befehle ausführen kann.

Bei einem Cronjob ist dem nicht so; er muss zuerst den Webserver infiltrieren und danach ein potentielles SIcherheitsloch im Datenaustausch zwischen Frontend und Backend finden. In der Annahme dass das Frontend das Backend nicht grade mit den reinen Shell-Befehlen sondern abstrakten Kommandos wie "starte Gameserver X" füttert, wird das sehr kompliziert an zu greifen.