Session-berechtigungen... und der Support weiss nicht weiter

[klyx]

Hallo zusammen

Ich stehe vor einem rätselhaften Problem und nicht mal der Support der Firma weiss Bescheid. Da es sowohl für mich als auch für andere Nutzer, die Webs auf dem Server haben, nervig ist, hoffe ich nun auf eure Hilfe.
Bei gewissen Scripts (vorwiegend Login-Scripts, weil meistens nur da die Sessions benötigt werden im Moment) bekomme ich oftmals eine Fehlermeldung in der folgenden art:

Code: Select all

Warning: session_start() [function.session-start]: open(/var/lib/php/sess_07222cb62a886165679e7476c7a55c42, O_RDWR) failed: Permission denied (13) in /srv/www/vhosts/abacado.net/subdomains/link/httpdocs/login.php on line 3

Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent (output started at /srv/www/vhosts/abacado.net/subdomains/link/httpdocs/login.php:3) in /srv/www/vhosts/abacado.net/subdomains/link/httpdocs/login.php on line 3

Warning: Cannot modify header information - headers already sent by (output started at /srv/www/vhosts/abacado.net/subdomains/link/httpdocs/login.php:3) in /srv/www/vhosts/abacado.net/subdomains/link/httpdocs/login.php on line 36

Warning: Unknown(): open(/var/lib/php/sess_07222cb62a886165679e7476c7a55c42, O_RDWR) failed: Permission denied (13) in Unknown on line 0

Warning: Unknown(): Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/lib/php) in Unknown on line 0

Manchmal hilft das löschen der Cookies und des Chaches, dass es mal eine Weile geht, aber der Fehler tritt immer wieder auf. Interessanterweise nicht immer und es ist nicht nachzuvollziehen wann er auftaucht und wann nicht. Manchmal hilft auch das Löschen des Caches und der Cookies nichts.
Die Scripts, die damit arbeiten, sind korrekt und haben keine Fehler (unter Anderem der Joomla Login ist eines der Scripte).

Der Supporter schaute ein wenig tiefer im System nach und kam auf folgendes:
Die Ursache scheint ein Berechtigungsproblem der Session Dateien zu sein.

rocoto018:/var/lib/php # ls -l
insgesamt 16
drwxr-xr-x 2 wwwrun root 12288 2007-12-13 10:03 .
drwxr-xr-x 30 root root 4096 2007-12-12 20:15 ..
-r-------- 1 wwwrun www 0 2007-12-13 10:01 sess_1d500835b154d042299efcc82afe58d1
-rw------- 1 wwwrun www 0 2007-12-13 10:03 sess_d2abb745f01aa2ac4ab822d8732fb197

Die erste Session Datei verursacht den Fehler. Löscht man diese bzw. ändert die Rechte, ist der Fehler verschwunden.
Weshalb die Session Datei sporadisch mit den falschen Rechten angelegt wird ist uns bislang jedoch unbekannt.

Aber das wars dann schon. Mehr konnte er mir auch nicht sagen und weder die Ursache noch die Lösung ist ihm bekannt.

Ich hatte das Problem schonmal und haben anschliessend den Server neu aufgesetzt. Seit dem ging es bis eben vor ca 2 Monaten.
Gemacht habe ich am Server nichts spezielles, von daher ist das auch komisch.

Habt ihr Ideen? Vorschläge? Lösungen?

Herzlichen Dank schon jetzt.
KlyX

[oxygen]

Der Session Pfad ist falsch eingestellt, dort gehören die Dateien nun wirklich nicht hin.

[klyx]

Und wer hat den eingestellt?
Naja, werd das so mal weitersagen.
Aber kannst nur am Pfad liegen? Ich meine, im Endeffekt spielt es ja keine Rolle, solange er die Berechtigungen hat.

[klyx]

So, der Support hat mal alles kontrolliert. Pfade und Rechte sind alle korrekt.

Vielleicht was zum System: Läuft auf SuSE Linux (jaja, ich weiss, nicht das beste Serversystem ) und PLESK 8.2 als Administrationsoberfläche.

Gibts weitere Ideen? weil das ist irgendwie unhaltbar so

[suntzu]

So, der Support hat mal alles kontrolliert. Pfade und Rechte sind alle korrekt.

Die (Session-)Cookies sollten aber am Besten in einem temp-Pfad landen, nicht in /var.

Vielleicht was zum System: Läuft auf SuSE Linux (jaja, ich weiss, nicht das beste Serversystem ) und PLESK 8.2 als Administrationsoberfläche.

"Das beste Serversystem" gibt es wohl nicht, das Hauptproblem ist in den seltensten Fällen die Wahl des OS/der Distribution als vielmehr die Wahl des Administrators.

Gibts weitere Ideen? weil das ist irgendwie unhaltbar so

Ändert mal den Session-Pfad und schaut, ob genügend Speicherplatz vorhanden ist.

[oxygen]

So, der Support hat mal alles kontrolliert. Pfade und Rechte sind alle korrekt.

Die (Session-)Cookies sollten aber am Besten in einem temp-Pfad landen, nicht in /var.

Jein. Am besten sollte der Session Pfad User bezogen eingestellt werden.

[suntzu]

So, der Support hat mal alles kontrolliert. Pfade und Rechte sind alle korrekt.

Die (Session-)Cookies sollten aber am Besten in einem temp-Pfad landen, nicht in /var.

Jein. Am besten sollte der Session Pfad User bezogen eingestellt werden.

OK, "natuerlich", Asche ueber mein Haupt Also am Besten in sowas wie /home/user/temppath oder so.

[klyx]

Mr. vom Support schrieb auf meine Anfrage hin wieder:

das Problem ist, dass Plesk den Pfad bestimmt und mir derzeit nicht bekannt wäre, das man dies ändern kann.
Es macht jedoch letztlich keinen Unterschied in welchem Verzeichnis die Sessions abgelegt werden wenn die Rechte entsprechend passen.
Daher kann ich diesen Vorschlag nicht wirklich nachvollziehen.

Vielleicht frag ich mal im Forum von PLESK nach...
Naja. Wenn wer noch ne Idee hat, nur zu... Den Pfad können wir also mal nicht ändern zurzeit... laut Support.

KlyX

[bernsteinkater]

Der session.save_path wird nicht von Plesk vorgegeben sondern in der php.ini vordefiniert.

http://www.php.net/manual/en/ref.sessio ... .save-path

Die Option kann auch ueber eine vhost.conf oder eine .htaccess ueberschrieben werden (PHP_INI_ALL). Da Plesk eigentlich standardmaessig als open_basedir das DocumentRoot + /tmp setzt verstehe ich die Aussage Deines Supports nicht. Dass es letztlich keinen Unterschied macht wo die Sessions gespeichert werden solange es ueberhaupt moeglich ist ist allerdings richtig. Das Problem wird hoechstwahrscheinlich nicht daran liegen, dass die Sessions in /var/lib/php gespeichert werden.

Zu dem Problem an sich kann ich Dir aber leider nicht weiterhelfen, ich habe keine Idee warum die Rechte manchmal nicht richtig gesetzt werden.

[stanglwirt]

das problem kann durchaus an dem session.save_path liegen, da auf dem webserver wohl einige webseiten liegen mit verschiedenen benutzern. (der pfad kann im übrigen auch im php-script mit ini_set() selbst eingestellt werden)

die session-dateien werden mit dem jeweiligen benutzer angelegt. wenn nun eine andere webseite zufällig eine session-datei mit der gleichen SID anlegen will, erhält diese eine zugriffsverweigerung, weil die datei bereits existiert und jemanden anderen gehört.
das erklärt auch, weshalb der fehler nicht immer auftritt und zeigt, daß das bei vielleicht 1000 webseiten auf dem server, garnicht so selten vorkommt, dass gleiche SIDs erzeugt werden - was aber natürlich ein großes Sicherheitsproblem ist.

von daher: der "support" hat wirklich keinerlei ahnung. würde als temporäre lösung den session pfad selber ändern und als richtige lösung den provider wechseln---