Skript über PHP (sudo) anderes Ergebnis als über bash??

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hallo,

    ich stehe gerade mächtig auf dem Schlauch:

    Bisher hat es -bis zu irgend einem update- normal funktioniert.

    Ich habe im apache eine php Seite, die mir Infos zum aktuellen Raspi anzeigt. U.a. prüfe ich, ob der openvpn-Server läuft.

    1. Ich habe in /var/www/skripte/GetInfos.sh ein skript, dass root ausführen darf.

    2. Dann gibt es noch ein Skript in /var/www/skripte/start.sh, das ebenfalls Root aufrufen darf und in Konsquenz das Skript aus 1. aufruft.

    3. in sudoers habe ich folgendne Eintrag: www-data ALL=NOPASSWD:/var/www/skripte/start.sh

    (Der Umweg oben über das start.sh Skript ist, weil dort noch mehr Skripte als root ausgeführt werden sollen, die ich hier sammle, damit sudoers nicht zu unübersichtlich wird).

    4. in

    5. Rufe ich mit root oder als normaler Benutzer mit sudo das Skript

    Code
    /var/www/skripte/start.sh 3

    oder auch direkt das GetInfos.sh mit sudo auf

    Code
    /var/www/skripte/GetInfos.sh

    bekomme ich als Ausgabe:

    root

    1

    [...]

    (wobei die erste Zeile zu Testzwecken der aufrufende Benutzer "whoami" ist).

    Die 1 sagt aus, der OpenVPN Server läuft, so sollte es sein.

    Rufe ich nun im PHP die Variable $output[1] auf (zweite Zeile), hat diese den Wert "0" statt "1", dabei enthält $output[0] den Benutzer "root".

    Das Skript wird jedoch augenscheinlich als ROOT ausgeführt (whoami), hat aber ein anderes Ergebnis, als wenn ich es über BASH aufrufe....

    Es hat, wie gesagt, bereits über Jahre funktioniert?!

    Wo ist mein Denkfehler???

    Greets

    Byte:conf:

  • Skript über PHP (sudo) anderes Ergebnis als über bash??? Schau mal ob du hier fündig wirst!

  • Rechtefehler

    -- kannst Du Dir mit < ls -al /var/www/html >, < ls -al /var/www/scripte > anzeigen lassen,

    -- werden weder durch chmod 777, noch durch sudo www-data beseitigt, sondern nur verschleiert

    -- treten auch dann auf, wenn der aufrufende Client nicht auf ein Ausgabedevice des Servers schreiben kann/darf.

    Servus !

    --

    RTFM = Read The Factory Manual, oder so

  • Hallo,

    also an den Rechten habe ich nichts geändert, waren schon immer so (also auch, als es noch funktionierte...):

    Das Skript läuft ja auch (über php gestartet und als root laut Ausgabe) und gibt plausible Rückgabewerte, nur im Punkt OpenVPN-Server weicht es ab.

    ls -al /var/www/skripte

    [...]

    -rwxr--r-- 1 root root 1600 Sep 4 18:01 GetInfos.sh

    -rwxr--r-- 1 root root 2985 Feb 23 2016 start.sh

    [...]

    /var/www/skripte/GetInfos.sh


    Greets

  • Ich schon, aber sudo www-data wird von mit nicht unterstützt.

    Und die beiden Files und deren Rechte sind auch nur die halbe Miete. Nicht umsonst habe ich ls -al auf die Verzeichnisse gesetzt.

    Herr der ganzen Prozesskete ist der Eigentümer von /var/www/html/index.php, wenn der Webserver verwendet wird.

    Wenn der (vermutlich www-data) das Pidfile /tmp/openvpn_server.pid lesen und schreiben (=löschen) kann, würde es mMn funktionieren. Mit < ls -l /tmp/openvpn_server.pid > findest Du es raus.


    Servus !

    RTFM = Read The Factory Manual, oder so

    Einmal editiert, zuletzt von RTFM (7. September 2018 um 00:10)

  • OK, dann habe ich ein Verständnisproblem.

    Wenn ein Skript per SUDO ausgeführt wird, wird es doch als root ausgeführt, oder?

    (Also so, als hätte es ROOT selbst gestartet).

    Dies sagt mir auch die "whoami"-Ausgabe im Skript selber.

    Dann hätten alle im Skript ausgeführten Befehle doch auch root-Rechte?

    Damit wäre der www-data Benutzer doch obsolet?

    Ich habe dem www-data-Benutzer im sudoers die sudo-Rechte für das Skript erteilt.

    Wo ist mein Denkfehler?!

    ls -l /tmp/openvpn_server.pid

    -rw-r--r-- 1 root root 4 Nov 3 2016 /tmp/openvpn_server.pid

    Davon abgesehen haben nach dieser Rechteausgabe ALLE Benutzer das Leserecht, was doch für ein "cat" wie es im Skript verwendet wird ausreicht, oder?


    Greets

    Byte

    2 Mal editiert, zuletzt von Bytechanger (8. September 2018 um 10:29)

  • sudo www-data wird von mit nicht unterstützt.

    Das betrifft auch eine Antwort auf Deine Fragen.


    Wenn Du www-data aus den sudoers und der Gruppe sudo wieder entfernst, habe ich eine mögliche Lösung für Dich, da ja der User Pi die Scipte erfolgreich ausführen kann.


    Servus !

    RTFM = Read The Factory Manual, oder so

  • sudo www-data wird von mit nicht unterstützt. ?? Ich vermute es soll von MIR heissen?!

    Ich verstehe das Problem nicht, könntest Du das bitte erläutern?

    Ich mag es nicht, wenn man dumm gehalten wird.

    Ich muss m.E. auf sudo zurückgreifen, da ich über die Web-Oberfläche reboots, und andere Dinge steuer möchte?!

    Der apache ist auf einem Raspi, und nicht über das wan erreichbar, nur lokal, zur Info-Anzeige und zum steuern...

    Also, über sudoers wird nur das eine Skript für sudo erlaubt und nicht alles...

    Für eine Erläuterung dieser Verweigerungshaltung wäre ich dankbar.

    Natürlich nehme ich gerne eine Alternative an, wenn ich damit auch die anderen Dinge erledigen kann...

    Ich lerne immer gerne dazu.


    Greets

    Byte

  • Weil es bereits einen sudoer gibt, der alles am Pi als root darf, und das ist schon fast einer zuviel.

    .

    Jedermann der den Port Deines Webservers erreicht, wird - ohne Login & Passwd - zum user www-data und kann dadurch auch mögliche sudo Bugs ausnützen und die Kontrolle über Deinen Host (einschl. openvpn-Server) übernehmen. Davon merkst Du vorerst nichts.

    Deshalb gibt es schon seit 2002, aufgrund einer Einigung aller Computerhersteller (einschliesslich Microsoft) die weltweit einheitliche Möglichkeit, die Filerechte über eine access contoll list = ACL, zu erweitern. So kann der Eigentümer eines Files anderen Usern, oder Gruppen erlauben, "sein" File so zu verwenden, als ob er selbst der Eigentümer wäre. Diese POSIX Regelung ging an der Pi(-Linux) Community ziemlich unbemerkt vorrüber, hier wird noch immer mit chmod777 und sudo "angeleitet".

    Wenn Du den user www-data das File

    -rwxr--r-- 1 root root 1600 Sep 4 18:01 GetInfos.sh

    als user root ausführen lassen willst, dann setzt der user root mit "set file acl"-modify :

    < setfacl -m u:www-data:rwx /Pfad/zu/GetInfos.sh >

    Genauso bei

    -rwxr--r-- 1 root root 2985 Feb 23 2016 start.sh

    < setfacl -m u:www-data:rwx /Pfad/zu/start.sh >

    Siehe < man acl, [setfacl, getfacl] >, oder setfacl --help u.s.w.


    Servus !

    RTFM = Read The Factory Manual, oder so

  • Danke für die Info.

    Allerdings habe ich das sudo auf EIN Skript beschränkt. www-data darf also NUR das start.sh als sudo ausführen UND dieses Skript ist NUR durch Root beschreibbar (veränderbar). Dachte, damit wäre es sicher....

    Gelesen habe ich nun, dass als Root oder sudo per bash anders ist als mit www-data sudo ?!?! Warum, keine Ahnung. Und dies ERST seit update auf Stretch!! Vorher lief es!


    Wie kann ich nun mit dem von Dir angesprochenen -aber noch nicht aufgezeigten - Lösungsweg das Problem lösen?

    Greets

    Byte

    Einmal editiert, zuletzt von Bytechanger (8. September 2018 um 17:08)

  • Wenn Du den user www-data das File

    -rwxr--r-- 1 root root 1600 Sep 4 18:01 GetInfos.sh

    als user root ausführen lassen willst, dann setzt der user root mit "set file acl"-modify :

    < setfacl -m u:www-data:rwx /Pfad/zu/GetInfos.sh >


    Genauso bei

    -rwxr--r-- 1 root root 2985 Feb 23 2016 start.sh

    < setfacl -m u:www-data:rwx /Pfad/zu/start.sh >

    Siehe < man acl, [setfacl, getfacl] >, oder setfacl --help u.s.w.


    Servus !

    RTFM = Read The Factory Manual, oder so

  • OK, danke für die Info:

    ich habe nun:

    setfacl -m u:www-data:rwx /var/www/skripte/start.sh

    setfacl -m u:www-data:rwx /var/www/skripte/GetInfos.sh

    gesetzt, so dass

    ls -la /var/www/skripte

    -rwxrwx---+ 1 root root 1600 Sep 9 10:01 GetInfos.sh

    -rwxrwx---+ 1 root root 2985 Feb 23 2016 start.sh

    ergibt.

    SUDO habe ich aus den skripten und dem PHP exec entfernt.

    Nun starten die Skripte trotzdem, whoami ergibt auch www-data als user...

    ABER, das Ergebnis bleibt gleich, angeblich läuft der OpenVPN-Server nicht.

    Das Problem muss irgendwo anders liegen, wie gesagt, Bash start des GetInfos.sh ergibt ["root",1,....]

    Ausgabe über php ergibt ["www-data",0,...].

    Inhalt der Skripte habe ich ja gepostet...

    Ich bin also noch keinen Schritt weiter.

    Greets

    Byte

  • Du hast aber auch die Rechte von

    -rwxr--r-- 1 root root 1600 Sep 4 18:01 GetInfos.sh

    auf

    rwxrwx---+ 1 root root 1600 Sep 9 10:01 GetInfos.sh

    geändert und damit der Gruppe root auch wx-Rechte eingeräumt und den Usern -other selbst die Leserechte entzogen.

    Das ist nicht durch setfacl passiert !

    Setz das wieder auf rwxr--r--+ (root root) zurück, auch bei dem anderen File, root-Gruppen wx-Rechte brauchst Du hier nicht, weil das File schin dem user root rwx gehört. Du baust damit nur eine weitere Fehlerquelle ein.

    Das + bei den Rechten bedeutet, dass die ACL gesetzt ist. Dann bekommst Du alle Rechte nur mit getfacl angezeigt.


    Servus !

    RTFM = Read The Factory Manual, oder so

  • Geändert:

    -rwxr--r--+ 1 root root 1737 Sep 9 10:11 GetInfos.sh

    -rwxr--r--+ 1 root root 2985 Feb 23 2016 start.sh

    getfacl /var/www/skripte/start.sh

    getfacl: Entferne führende '/' von absoluten Pfadnamen

    # file: var/www/skripte/start.sh

    # owner: root

    # group: root

    user::rwx

    user:www-data:rwx #effective:r--

    group::---

    mask::r--

    other::r--

    getfacl /var/www/skripte/GetInfos.sh

    getfacl: Entferne führende '/' von absoluten Pfadnamen

    # file: var/www/skripte/GetInfos.sh

    # owner: root

    # group: root

    user::rwx

    user:www-data:rwx #effective:r--

    group::---

    mask::r--

    other::r--


    Zusatzfrage: Wenn www-data das start.sh skript ausführen darf, mit den Rechten von root, werden dort gestartete Skripte und Befehle auch als root gestartet, wie bei sudo ? Ich glaube schon?


    Und nun startet das Skript nicht mehr unter www-data?!

    Mit Sudo gehts wieder, also erneut ein Rechteproblem aufgemacht?

    Beim Debuggen mit sudo bin ich so weit gekommen, dass es wohl daran liegt, das das File /tmp/openpvn_server.pid mit cat nicht ausgelesen werden kann, es gibt leer zurück....

    Obwohl rechtemäßig alle Lesen dürfen

    -rw-r--r-- 1 root root 4 Nov 3 2016 openvpn_server.pid

    tmp-Verzeichnis

    drwxrwxrwt 12 root root 4096 Sep 9 13:16 tmp


    Greets

    Byte

    Einmal editiert, zuletzt von Bytechanger (9. September 2018 um 13:16)

  • Wenn ein Shellscript gar nicht startet har es wahrscheinlich keine Shell (AKA Shebang) und/oder kein, oder ein falsches Environment (Umgebungsvariablen).

    Sudo vererbt normalerweise keine Rechte des substituierten Users. Es ruft nur einen Prozess/Unterptozess als substituierter User auf.

    Ist eigentlich das "rm pid (OpenVPN Server)" in Zeile 24 von GetInfos.sh der einzige Grund, warum der iser www-data in seiner "Sandbox" fremdgehen muss ?


    Servus !


    Edit: Oder das index.php gehört gar nicht www-data

    RTFM = Read The Factory Manual, oder so

    Einmal editiert, zuletzt von RTFM (9. September 2018 um 16:29)

  • OK, so viele infos.

    1. Das PID File ist nicht leer ! Nur das skript mit sudo vom www-data aus aufgerufen ergibt das cat blabla.pid "" (als wäre es leer)

    Tatsächlich steht dort aber die PID Nummer drin! wenn ich es mit root cat blabla.pid ausgeben lasse, ist es drin

    2. als das skript noch ohne sudo funktionierte, (bevor ich die gruppenberechtigung entfernte), wurde bei whoami www-data angezeigt,

    daher bin ich überzeugt, dass index.php als www-data arbeitet.

    Also, wenn ich chmod g+x /var/www/skripte/* setze, läuft das Skript wieder und whoami gibt dann www-data aus.

    3. das rm blabla.pid ist derzeit nicht mein Problem, sondern, siehe 1./bzw. 2.

    Greets

    Byte

    EDIT: Das bringt mich zu der Frage, gibt es in einer neuen Apache oder PHP Version die Einschränkung, das Skripte das /var/www/ Verzeichnis nicht verlassen dürfen? Das würde erklären, dass ein Zugriff auf eine Datei in /tmp/ nicht zulässig ist!!!

    Wenn ja, kann man die Berechtigung auf /tmp/ erweitern???

    Eine sogenannte Sandbox??

  • So, Problem gelöst!

    Stichwort: PrivateTmp!


    Der Apache Prozess hat ein eigenes TMP bekommen, konnte folglich nicht auf die PID Datei zugreifen!

    /etc/systemd/system/multi-user.target.wants/apache2.service

    angepasst und PrivateTmp auf false gesetzt, fertig!

    Greets

    Byte

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!