Zugriff verboten beim Schreiben der Session

[Samson1964]

Ich bekomme in C 4.4.8 auf dem ManagedServer nach jeder 10.-20. Speicherung im BE die folgende Fehlermeldung:

Notice: SessionHandler::gc(): ps_files_cleanup_dir: opendir(/tmp) failed: Permission denied (13)

Symfony\Component\Debug\Exception\ ContextErrorException
in vendor/symfony/symfony/src/Symfony/Component/HttpFoundation/Session/Storage/Proxy/SessionHandlerProxy.php (line 86)

SessionHandlerProxy->gc(1440)
session_start() in vendor/symfony/symfony/src/Symfony/Component/HttpFoundation/Session/Storage/NativeSessionStorage.php (line 146)

NativeSessionStorage->start() in vendor/symfony/symfony/src/Symfony/Component/HttpFoundation/Session/Storage/NativeSessionStorage.php (line 288)

NativeSessionStorage->getBag('attributes') in vendor/symfony/symfony/src/Symfony/Component/HttpFoundation/Session/Session.php (line 243)

Session->getAttributeBag() in vendor/symfony/symfony/src/Symfony/Component/HttpFoundation/Session/Session.php (line 63)

Session->has('_locale') in vendor/contao/core-bundle/src/EventListener/LocaleListener.php (line 117) 
.....

Nach einem Refresh ist wieder alles okay.

[vini]

Ich bekomme die gleiche Fehlermeldung, aber Pfad unterscheidet sich –

opendir(/tmp/phpfpmsessions/)

Und der Pfad existiert auf meinem Server nicht. Und das passiert mehrmals jeden Tag.

Contao 4.4.12, all-inkl

[Samson1964]

Seit dem 27.12. läuft meine Installation auf einer anderen Domain, die mit Sicherheit etwas andere PHP-Einstellungen hat, sich aber nur minimal von der alten Domain unterscheiden wird (gleicher Server). Das Problem trat seit dem Domainwechsel nicht mehr auf. Das Verzeichnis auf dem Server habe ich nicht gewechselt.

[webstar]

Kenne den Fehler auch von all inkl. Das Problem ist wohl, dass alle kunden-Instanzen in den selben temporären Ordner schreiben und PHP dann beim bereinigen der Session auch die löschen möchte, auf die er keine Schreibrechte hat.

Am besten den Support von all inkl kontaktieren. Hatte damals keinen Erfolg, aber der stete Tropfen...

[Samson1964]

Mist. Kaum schreibe ich, ich kenne das nicht mehr. Und schon ist der Fehler wieder da. Allerdings nur im Dev-Modus. Im Prod-Modus kommen diese Warnings nicht.

[Spooky]

Hast du schon auf Contao 4.4.12 aktualisiert?

[webstar]

Mist. Kaum schreibe ich, ich kenne das nicht mehr. Und schon ist der Fehler wieder da. Allerdings nur im Dev-Modus. Im Prod-Modus kommen diese Warnings nicht.

In der prod Umgebung werden die Meldungen einfach unterdrückt.

[webstar]

Hast du schon auf Contao 4.4.12 aktualisiert?

Warum sollte sich dann etwas am Session Handling von PHP ändern?

[Samson1964]

Hast du schon auf Contao 4.4.12 aktualisiert?

Oh, schon 12
Über die Konsole ging das Update schief. Aber oh Wunder: mit dem aktuellen Contao-Manager wurden alle Pakete und auch der Core problemlos aktualisiert.

[do_while]

Was hälst Du davon, Dir ein eigenes tmp-Verzeichnis anzulegen?
Erstelle in der Webspace-Root ein Verzeichnis /tmp und eine .htaccess, die folgende Zeilen enthält:

php_value session.save_path "/www/htdocs/w1234567/tmp"
php_value session.gc_probability 1

(* w1234567 musst Du mit Deiner Kennung ersetzen)

[Spooky]

Über die Konsole ging das Update schief.

Mit welcher Fehlermeldung?

[Samson1964]

(14:45:42) [web] php contao-manager.phar.php composer update contao/core-bundle
Loading composer repositories with package information
Updating dependencies (including require-dev)
Nothing to install or update
Generating autoload files
> Contao\ManagerBundle\Composer\ScriptHandler::initializeApplication

 Added/updated the web/app_dev.php file.
 Added/updated the web/app.php file.

 // Clearing the cache for the prod environment with debug false


 [OK] Cache for the "prod" environment (debug=false) was successfully cleared.



 // Warming up the cache for the prod environment with debug false

Script Contao\ManagerBundle\Composer\ScriptHandler::initializeApplication handling the post-update-cmd event terminated with an exception


  [Symfony\Component\Process\Exception\ProcessTimedOutException]
  The process "'/usr/local/bin/php5.6.30-cli' '/xxx/vendor/contao/manager-bundle/src/Composer/../../bin/cont
  ao-console' --ansi cache:warmup --env=prod" exceeded the timeout of 60 seconds.


update [--prefer-source] [--prefer-dist] [--dry-run] [--dev] [--no-dev] [--lock] [--no-custom-installers] [--no-autoloader] [--no-scripts] [--no-progress] [--no-suggest] [--with-dependencies] [-v|vv|vvv|--verbose] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-autoloader] [--ignore-platform-reqs] [--prefer-stable] [--prefer-lowest] [-i|--interactive] [--root-reqs] [--] [<packages>]...

Die beiden Abschnitte unter "// Warming up" in weiß auf rot dargestellt.
Der Contao-Manager verwendete wohl PHP 7.1. Jedenfalls fand er die Version beim Starten.

[Spooky]

Du musst auch auf der Konsole die richtige PHP Version verwenden. Also die PHP Version, die dein Webserver für den VHost deiner Webapplikation benutzt.

Zu dem Problem siehe https://github.com/contao/manager-bundle/issues/54

[Samson1964]

Du musst auch auf der Konsole die richtige PHP Version verwenden. Also die PHP Version, die dein Webserver für den VHost deiner Webapplikation benutzt.

Zu dem Problem siehe https://github.com/contao/manager-bundle/issues/54

Ich habe das Alias php auf PHP 7.1 umgestellt. Jetzt läuft auch die Konsole sauber durch.

[webstar]

Was hälst Du davon, Dir ein eigenes tmp-Verzeichnis anzulegen?
Erstelle in der Webspace-Root ein Verzeichnis /tmp und eine .htaccess, die folgende Zeilen enthält:

php_value session.save_path "/www/htdocs/w1234567/tmp"
php_value session.gc_probability 1

(* w1234567 musst Du mit Deiner Kennung ersetzen)

Greift das bei dir auch bei einer abweichend eingestellter PHP-Version? Das war nämlich auch mein Gedanke, funktioniert hatte es aber nicht.

[Samson1964]

In der FAQ von Domainfactory steht zu der Fehlermeldung übrigens:

Aus Sicherheitsgründen ist es auf unseren Servern nicht erlaubt, das "tmp" Verzeichnis nach Dateien zu durchsuchen oder auf Dateien zu zugreifen deren Namen man nicht kennt. Auch ist ein Ändern oder Löschen von Dateien nur noch möglich, wenn diese von Ihnen bzw. Ihren Skripten erstellt wurden. Das ist auch die Ursache für die ausgegebene Meldung:
Notice: session_start(): ps_files_cleanup_dir: opendir(/tmp) failed: Permission denied (13) in /kunden/example.com/....
Diese Meldung erscheint in der Standardeinstellung von PHP nicht, man muss das Error Reporting von PHP manuell umstellen, um auch Notice Meldungen angezeigt zu bekommen. Sie könnten das in den betreffenden Skripten deaktivieren, bzw. sich dafür an die Entwickler der Skripte wenden.
Es besteht durch dieses Verhalten nicht die Gefahr, dass der vorhandene Webspace durch temporäre Dateien unnütz verbraucht wird, da diese von uns regelmäßig (alle drei Tage) gelöscht werden.
Alternativ zur Benutzung des Standard-"tmp"-Verzeichnisses haben Sie auch die Möglichkeit, PHP mitzuteilen, wohin die Sessions gespeichert werden sollen.

Jetzt frage ich mich natürlich warum Contao in Verzeichnissen rumwirtschaften will, die Contao nichts angehen.

[Spooky]

Jetzt frage ich mich natürlich warum Contao in Verzeichnissen rumwirtschaften will, die Contao nichts angehen.

Mit Contao hat das Problem nichts zu tun. Siehe auch zB https://www.leaseweb.com/labs/2012/0...ission-denied/

Bei DomainFactory sollte die PHP Einstellung session.gc_probability also auf 0 gesetzt sein. Ist es das nicht, ist das ein Konfigurationsfehler von DomainFactory.

[webstar]

In der FAQ von Domainfactory steht zu der Fehlermeldung übrigens:

Jetzt frage ich mich natürlich warum Contao in Verzeichnissen rumwirtschaften will, die Contao nichts angehen.

Weil der Server so konfiguriert ist. In den PHP Einstellungen wird der temporäre Ordner festgelegt. Hier geht weiterhin es um die PHP-Session. Das ist Konfigurationssache des Providers, wo dann die Sessions gespeichert werden.

[Samson1964]

Mit Contao hat das Problem nichts zu tun. Siehe auch zB https://www.leaseweb.com/labs/2012/0...ission-denied/
Bei DomainFactory sollte die PHP Einstellung session.gc_probability also auf 0 gesetzt sein. Ist es das nicht, ist das ein Konfigurationsfehler von DomainFactory.

Für mich hat das Problem sehr wohl mit Contao zu tun - auch wenn in Wirklichkeit Symfony der Schuldige ist. Wenn Symfony nicht schuldig gesprochen werden soll, ein (unerlaubtes) Cleanup des Temp-Ordners durchzuführen, dann sollte sich Contao von Symfony trennen.

Ich habe in der php.ini session.gc_probability jetzt auf 0 gestellt und werde das auch noch im GitHub-Wiki posten.

[lucina]

Was genau an 'Es ist die PHP-Einstellung, die bestimmt, wo sich der temporäre Ordner befindet' hast du jetzt nicht verstanden?

[Spooky]

Für mich hat das Problem sehr wohl mit Contao zu tun - auch wenn in Wirklichkeit Symfony der Schuldige ist. Wenn Symfony nicht schuldig gesprochen werden soll, ein (unerlaubtes) Cleanup des Temp-Ordners durchzuführen, dann sollte sich Contao von Symfony trennen.

Es hat auch nichts mit Symfony zu tun.

[Spooky]

Was genau an 'Es ist die PHP-Einstellung, die bestimmt, wo sich der temporäre Ordner befindet' hast du jetzt nicht verstanden?

Wo sich der /tmp Ordner befindet ist hier nicht direkt das Problem.

[tab]

Wenn Symfony nicht schuldig gesprochen werden soll, ein (unerlaubtes) Cleanup des Temp-Ordners durchzuführen, dann sollte sich Contao von Symfony trennen.

So wie das da laut DF wohl konfiguriert ist, ist das /tmp Verzeichnis einfach nicht als Verzeichnis für die PHP sessions geeignet. Aus meiner Sicht schon deshalb, weil ja DF dieses Verzeichnis alle 3 Tage (unerlaubt) löscht. Dass PHP dieses Verzeichnis dafür hernimmt, liegt an der PHP-Konfiguration, nicht an Contao oder Symfony. Für die PHP-Konfiguration ist der Hoster verantwortlich - oder falls du Einflussmöglichkeiten darauf hast (php.ini) eben du. Das Verzeichnis für die Session-Daten kann sogar auf mehrere Arten geändert werden. Einmal, indem das temporäre Verzeichnis anders eingestellt wird (sys_temp_dir) und dann gibt es noch eine eigens für die Session-Daten gedachte Einstellung (session_save_path) Bei anderen Hostern, die das ähnlich machen und die Sessions in /tmp speichern, kann dieses Verzeichnis gefahrlos von jedem User geleert werden, weil jeder sowieso nur das Recht dazu hat seine eigenen Dateien in diesem Ordner zu löschen. Der Rest, die Dateien der anderen User, bleibt dann halt erhalten, ist ja auch besser so .

Sie hierzu auch http://php.net/manual/de/function.session-save-path.php, hier wird sogar explizit davor gewarnt /tmp dafür zu benutzen.

[Spooky]

So wie das da laut DF wohl konfiguriert ist, ist das /tmp Verzeichnis einfach nicht als Verzeichnis für die PHP sessions geeignet.

Doch, so wie das DF konfiguriert hat ist es korrekt.

Aus meiner Sicht schon deshalb, weil ja DF dieses Verzeichnis alle 3 Tage (unerlaubt) löscht.

Nein, auch das ist durchaus normal.

Dass PHP dieses Verzeichnis dafür hernimmt, liegt an der PHP-Konfiguration

PHP selbst "nimmt" dieses Verzeichnis nicht. PHP nimmt als temporäres Verzeichnis das, was im System als temporäres Verzeichnis hinterlegt ist, was auch korrekt ist. Auf Unix Systemen eben zB. /tmp

[tab]

Doch, so wie das DF konfiguriert hat ist es korrekt.

Naja, du hältst es also für normal, dass man Dateien im temporären Verzeichnis nur löschen kann, wenn man den sich den exakten Pfad jeder einzelnen von PHP erzeugten temporären Datei gemerkt hat? Ich nicht. Dann wäre es also doch Contao oder Symfony, die sich das Löschen zu einfach machen. Oder, wenn man den Schlussfolgerungen aus deinem Link folgen will, wäre PHP der "Schuldige", weil versucht wird, die Sessionfiles zu löschen.

Nein, auch das ist durchaus normal.

Das macht es aber nicht besser. Obwohl es eventuell andere Mechanismen geben mag, die verhindern, dass eine Session früher als eigentlich vorgesehen gelöscht wird. Das weiß ich nicht.

PHP selbst "nimmt" dieses Verzeichnis nicht. PHP nimmt als temporäres Verzeichnis das, was im System als temporäres Verzeichnis hinterlegt ist, was auch korrekt ist. Auf Unix Systemen eben zB. /tmp

Ja, Sofern kein anderer Pfad als session_save_path angegeben ist, wird die Session in das temporäre Verzeichnis des Systems geschrieben. Das ist eben das Default-Verhalten. Aber m.E. nicht notwendigerweise deshalb, weil das unter allen Umständen (Systemkonfiguration, Benutzerrechte, ...) das optimale Verzeichnis dafür wäre. Eher deshalb, weil man bei einer korrekten Systemkonfiguration dort immer Dateien erzeugen darf. Für ganz normale temporäre Dateien halte ich das auch für optimal, für die Sessiondaten nicht. Die Variable session_save_path wird ja hoffentlich nicht zum Spaß existieren. Oder nur deshalb, weil die PHP-Entwickler gemerkt haben, dass sie an anderer Stelle einen Fehler gemacht haben (Löschen von Sessiondaten).

[Spooky]

Naja, du hältst es also für normal, dass man Dateien im temporären Verzeichnis nur löschen kann, wenn man den sich den exakten Pfad jeder einzelnen von PHP erzeugten temporären Datei gemerkt hat?

Ja, PHP weiß ja wie die Datei für die jeweilige Session heißt. Wie soll PHP eine Session mit einer Session Datei auch sonst in Verbindung setzen können.

Oder, wenn man den Schlussfolgerungen aus deinem Link folgen will, wäre PHP der "Schuldige", weil versucht wird, die Sessionfiles zu löschen.

Ja, PHP löscht alte Session Files automatisch bei der Garbage Collection. Sonst würde das Verzeichnis ja mit alten Session Files voll geschrieben werden.

Das macht es aber nicht besser. Obwohl es eventuell andere Mechanismen geben mag, die verhindern, dass eine Session früher als eigentlich vorgesehen gelöscht wird.

Das passiert ja auch nicht bzw. das ist nicht der Fehler, um den es hier geht. Das Problem ist die Garbage Collection von PHP, die aber vom System unterbunden wird. Sobald das zutrifft, kommt es zu dieser Notice.

Man könnte, wie von DF ja auch schon erwähnt, diese Notices ja auch einfach nicht ausgeben lassen. Es ist ja nur ein Hinweis von PHP, dass die Garbage Collection das /tmp Verzeichnis nicht aufräumen hat können (weil der Verzeichnisinhalt nicht gelesen werden darf, aus Sicherheitsgründen) - was ja nicht weiter schlimm ist.

[tab]

Ok, also tatsächlich PHP bzw ein "falsch" gesetzter Wert für session.gc_probability, denn das auf 0 zu setzen scheint ja tatsächlich geholfen zu haben.

[Spooky]

Das bleibt noch abzuwarten.

Aber wenn dann ist es eine Fehlkonfiguration von DF.