www-data darf nicht lesen und schreiben - nähere Infos?

[encoder]

Hallo ihr

Vor einiger Zeit habe ich gelesen dass der User "www-data" unter dem Webzugriffe laufen nicht auf alles zugreifen darf, auch wenn die Permissions es hergeben würden.
Ich finde leider nichts mehr darüber. Wer kann mir helfen?

Ein paar Infos.
Auf einem Raspberry loggt ein cronjob regelmäßig mit einem php Script Daten von meiner PV Anlage. Das Script speichert zwischen den Aufrufen Daten auf einer ramdisk, damit nur Werte in meine Datenbank geschrieben werden die sich tatsächlich geändert haben.
Funktioniert soweit.

Nur wenn ich das Script als Debugversion zwecks schönerer Ausgaben im Browser aufrufe, darf es nicht auf die ramdisk zugreifen.
Permissions der ramdisk sind maximal offen und wenn ich das Script in der Shell mit sudo -u www-data starte, funktioniert es auch. Es scheint demnach ein weiterer Sperrmechanismus zugange zu sein.
Nach was muss ich suchen um mehr über ihn zu finden?

[Robert B.]

Moin encoder,

Vor einiger Zeit habe ich gelesen dass der User "www-data" unter dem Webzugriffe laufen nicht auf alles zugreifen darf, auch wenn die Permissions es hergeben würden.
Ich finde leider nichts mehr darüber. Wer kann mir helfen?

in welchem Kontext soll das denn der Fall sein? Ich wüsste nicht, dass das Betriebssystem jenseits von Dateiberechtigungen und ACLs hier eingriffe.

Allerdings haben einige Webumgebungen zusätzliche Einschränkungen, PHP z.B. open_basedir.

Nur wenn ich das Script als Debugversion zwecks schönerer Ausgaben im Browser aufrufe, darf es nicht auf die ramdisk zugreifen.

Was passiert denn da noch alles in der Debugversion im Unterschied zur produktiven Ausführung? Ich vermute, dass die Ursache in diesem Delta zu finden ist.

Permissions der ramdisk sind maximal offen und wenn ich das Script in der Shell mit sudo -u www-data starte, funktioniert es auch. Es scheint demnach ein weiterer Sperrmechanismus zugange zu sein.
Nach was muss ich suchen um mehr über ihn zu finden?

Du könntest das error_reporting so konfigurieren, dass alle Fehler gemeldet werden. (Je nach Konfiguration werden die Meldungen an den Client gesendet oder ins Apache error.log geschrieben.)

Viele Grüße
Robert

[encoder]

Was passiert denn da noch alles in der Debugversion im Unterschied zur produktiven Ausführung? Ich vermute, dass die Ursache in diesem Delta zu finden ist.

Es gibt nur Ausgaben an allen denkbaren Stellen.
Wenn ich das Script auf Debug umstelle, funktioniert der Zugriff auf die ramdisk wenn ich es von einer Shell aus als Web-User starte. Vom Browser aus nicht.

Du könntest das error_reporting so konfigurieren, dass alle Fehler gemeldet werden.

Error reporting hab ich an. Im Fehlerfall heißt es "Permission denied".
Der aktive User ist www-data, sowohl bei Browser als auch Shell.

[Robert B.]

Moin encoder,

Was passiert denn da noch alles in der Debugversion im Unterschied zur produktiven Ausführung? Ich vermute, dass die Ursache in diesem Delta zu finden ist.

Es gibt nur Ausgaben an allen denkbaren Stellen.
Wenn ich das Script auf Debug umstelle, funktioniert der Zugriff auf die ramdisk wenn ich es von einer Shell aus als Web-User starte. Vom Browser aus nicht.

ich kann mir nicht vorstellen, dass lediglich Debug-Ausgaben so einen großen Einfluss haben.

Wie wird denn das Debuggen eingeschaltet? Gibt es Unterschiede in den Umgebungsvariablen, im Skript-Aufruf, Verzeichnis, Pfad, effektiver User …?

Viele Grüße
Robert

[encoder]

ich kann mir nicht vorstellen, dass lediglich Debug-Ausgaben so einen großen Einfluss haben.

Die sind nicht schuld am fehlenden Zugriff. Die Ausgaben sind nur der Grund warum ich das Script überhaupt per Browseraufruf starten möchte. Und dort merke ich dass die ramdisk in diesem Fall nicht erreichbar ist.
Momentan sind die Ausgaben immer aktiv, damit ich da wirklich keinen Unterschied habe.

Der Unterschied ist also nur, wie das Script gestartet wird.
Beide Male läuft es als www-data. Nur eben einmal vom Apache aus gestartet und einmal von der Shell aus.

Gibt es Unterschiede in den Umgebungsvariablen, im Skript-Aufruf, Verzeichnis, Pfad, effektiver User …?

Tja… das müsste ich mir noch alles ansehen.

[Robert B.]

Moin encoder,

das ist doch eine sehr wichtige Information:

Der Unterschied ist also nur, wie das Script gestartet wird.
Beide Male läuft es als www-data. Nur eben einmal vom Apache aus gestartet und einmal von der Shell aus.

die PHP-Umgebung (der Ausführungskontext) ist in beiden Fällen nicht die gleiche, es gibt Unterschiede

• in den effektiven PHP-Konfigurationswerten
• den Umgebungsvariablen
• ggf. chroot
• andere Nutzergruppe, mit der der Prozess läuft
• … eventuell noch anderes …

Gibt es Unterschiede in den Umgebungsvariablen, im Skript-Aufruf, Verzeichnis, Pfad, effektiver User …?

Tja… das müsste ich mir noch alles ansehen.

Du kannst ja mit dem einfachsten Skript dafür anfangen:

<?php phpinfo();

Viele Grüße
Robert

[Felix Riesterer]

Lieber encoder,

Wenn ich das Script auf Debug umstelle, funktioniert der Zugriff auf die ramdisk wenn ich es von einer Shell aus als Web-User starte. Vom Browser aus nicht.

was ist der Unterschied zwischen „von einer Shell aus als Web-User“ und „vom Browser aus“? Im Grunde sollten doch alle Schreib- und Lese-Operationen vom PHP-Prozess des Apache ausgehen. Oder warum fragtest Du nach www-data?

Liebe Grüße

Felix Riesterer

[Rolf B]

Hallo Felix,

ich habe keine Ahnung, warum hier passiert, was passiert, aber das Szenario verstehe ich so:

(1) Script auf der Konsole starten, im Userkontext von www-data. PHP läuft jetzt im Konsolenkontext. Apache ist nicht beteiligt.

(2) Script über einen Webrequest vom Apache starten lassen. Die Mutmaßung ist, dass Apache das Script ebenfalls im Userkontext von www-data ausführt.

D.h. das gleiche Script läuft beide Male im gleichen Userkontext. Aber wenn der Apache es gestartet hat, darf es nicht an die RAMDisk. Es sieht also so aus, als dürfte www-data unterschiedliche Dinge, je nachdem, aus welchem Prozess der Aufruf kommt.

Frage eines Linux-DAUs: Muss die RAMDisk pro Prozess gemounted werden? Oder macht man das einmal und dann ist sie für alle Prozesse da?

Rolf

[encoder]

Richtig erkannt, genau das ist meine Situation.