PHP Script führt das Shell script nicht aus

Wär schlimm, wenn das funktionieren würde. Der User www-data führt ein Skript aus dem Verzeichnis des Users Pi aus, und das noch mit root-Rechten. So fangen Emmerlich-Filme an.

Quote from sugram

Hat da jemand nen Tipp für mich?

Sicher.
- Lege das Shell-Skript in den Wirkbereich des Webusers (verm. www-data). Aber so, das es nicht von außen erreichbar ist (z.B. statt /var/www/html nach /var/www/exec). Der Webuser muß Ausführ- und Leserechte an dem Verzeichnis und des darin liegenden Shell-Skriptes haben

- Da es mit root-Rechten laufen muß, erstelle mit visudo das besondere Recht des Webusers an dem Shellskript.

Quote from Bergwichtel

Wär schlimm, wenn das funktionieren würde. Der User www-data führt ein Skript aus dem Verzeichnis des Users Pi aus, und das noch mit root-Rechten.

In das Home Verzeichnis des Users pi kommt ein Fremder (www-data) inzwischen aber gar nicht mehr rein.

/home/pi drwx --- --- = 0700

Und "shutdown -h now" funktioniert bei mir auch ohne root-Rechte (schon länger)

Schon länger wurde auch Sys V durch systend ersetzt. "init 0" funktioniert auch nur, weil ein systemd Generator daraus (noch) eine systemd-Unit erstellt.

Servus !

Und www-data in jeglicher Form sudo zu erlauben, auch wenn es sich "nur" um *ein* Skript handelt, würde ich auch lassen. Dann lieber z.B. eine Datei in der Mitte (Besitzer www-data / Gruppe pi / Rechte: 640), in der man mit PHP ein Flag setzt und mit einem Skript, das pi gehört, regelmäßig auslesen und reagieren.

Quote from hyle

Und www-data in jeglicher Form sudo zu erlauben, auch wenn es sich "nur" um *ein* Skript handelt, würde ich auch lassen.

Warum? Man muß allerdings ein bischen was beachten. Nichts an dem Skript übergeben, das nicht vordefiniert ist und im Shell-Skript nur prüfen und nichts übernehmen.
Das könnte im mit sudo erlaubten Shellskript in etwa so aussehen: (bei den sudo-Berechtigungen dran denken: execute und read-Rechte, keinesfalls write-Rechte):

#!/bin/bash
# (ungetestet)
#
# shutdownscript für Webserver

logfile="/var/log/webshutdown.log"
myDate=$(date '+%Y-%m-%d %H:%M:%S')

if [ "$EUID" -ne 0 ]
  then echo "Please run as root"
    logger -f "$logfile" "$myDate $0 not run as root"
  exit 255
fi

case "$1" in
    godown)     logger -f "$logfile" "$myDate $0 System halt"
                shutdown -h now
    ;;
    restart)    logger -f "$logfile" "$myDate $0 System reboot"
                shutdown -r now
    ;;
    *)  logger -f "$logfile" "$myDate $0 call with false option"
        exit 1
esac
exit 0
# eof

Und aufgerufen wird es mit skriptname.sh godown oder skriptname.sh restart. Da gibt es nur das Risiko, das Dir jemand Deinen Rechner runterfährt. Ergo sollte man diesen Bereich auf dem Webserver entrprechend schützen.

Im übrigen halte ich sudo für den RPi-Hauptnutzer für weit problematischer.

Edit: Im Skript die vergessen Parameter bei logger fürs Logfile hinzugefügt.
Edit2: OMG, ich stehe heute voll neben meinen Schuhen. (Parameter für halt richtig gesetzt, logfile -> $logfile)

Quote from Bergwichtel

Warum?

Weil softwareseitig alles dafür getan wurde, damit ein Webserveruser in seinem Sandkasten bleibt und dann gibt man dem doch nicht die mächtigste Waffe in die Hand, die das System zu bieten hat. Ein kleiner Fehler reicht da aus und im besten Fall ist nur der RPi kompromittiert.

Quote from Bergwichtel

Im übrigen halte ich sudo für den RPi-Hauptnutzer für weit problematischer.

Der RPi-Hauptnutzer steht im Gegensatz zu einem Webserver nicht im Internet rum und will geklickt werden. Und jetzt kommt bestimmt wieder "mein Webserver ist nicht im Internet und nur in meinem Netzwerk erreichbar".

Du hast zwar zum "Warum" im Grunde recht. Deshalb habe ich ein Skript skizziert, wo sich die Bedenken in Grenzen halten.

Quote from hyle

Der RPi-Hauptnutzer steht im Gegensatz zu einem Webserver nicht im Internet rum

Jaja, dann schau mal, wie oft hier soetwas empohlen wurde:
curl https://raw.githubusercontent.com/.../master/install | sudo bash
Dagegen ist ein Webserver mit einem sudo-Skript lächerlich.

Quote from Bergwichtel

Jaja, dann schau mal, wie oft hier soetwas empohlen wurde

Genau aus solchen Gründen schrieb ich den Lexikoneintrag zu sudo. Ein Problem sehe ich da nur, dass sudo ohne Passwort funktioniert. Mit Passwort wären die Leute sehr wahrscheinlich viel sensibilisierter bei der Verwendung von sudo.

Quote from Bergwichtel

Dagegen ist ein Webserver mit einem sudo-Skript lächerlich.

Mag sein, aber nur deshalb die Systemrechte verbiegen macht es nicht besser.

Quote from sugram

Huch ... wollte jetzt hier keinen "Streit" anzetteln

Mach Dir keine Sorgen, wir diskutieren doch nur sachlich, aber streiten uns nicht.

Quote from sugram

Also das wird so oder so nur intern verwendet.

So eine Aussage habe ich erwartet, denn das höre und lese ich nicht zum ersten mal. Irgendwann hat man ggf. diesen Vorsatz vergessen und will seinen RPi auch aus dem Internet heraus bedienen und da ist das Risiko angegriffen zu werden enorm.

Quote from hyle

Ein Problem sehe ich da nur, dass sudo ohne Passwort funktioniert.

Leider ist das so beim RaspiOS. Das ist auch meist das erste, was ich ändere.
Bei jedem anderen Debian (amd) ist das ootB nur mit Passwort möglich.