Rootserver hat nach Serverumzug Probleme mit Zugriffsrechten

Michak

New Member
Hallo,

ich habe einen Rootserver bei Server4you. Mein Programmierer ist dabei mir ein Spiel zu programmieren. Das ganze läuft mit Sessions. Alles lief bisher problemlos. Nun war mein Programmierer 2 Monate in Zeitnot und das Projekt ruhte. Während der Zeit gab es einen Serverumzug bei S4You.
Seither gibt es ein Problem:
Ich rufe die Startseite des Spiels auf, alles soweit in Ordnung. Wenn ich nun das eigentliche Spiel starten will, bzw. mich als Spieler einloggen will, erhalte ich Fehlermeldungen.
Der Programmierer meint es seien mangelnde Zugriffsrechte die beim Serverumzug falsch gesetzt wurden. S4You ist der Meinung es ist unser Problem, da von ihrer Seite alles richtig ist.

Hier ein Auszug der Fehlermeldung:
Code:
Warning: session_start() [function.session-start]: open(/var/lib/php/session/sess_0c1173bcaaeaf0300f61d5fb95d20bef, O_RDWR) failed: Permission denied (13) in /srv/www/web1/html/testversion/src/classes/class.session.php on line 17 

Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent (output started at /srv/www/web1/html/testversion/src/classes/class.session.php:17) in /srv/www/web1/html/testversion/src/classes/class.session.php on line 17
Hier die Auskunft meines Programmierers:
Das Problem ist folgendes:
Der Apache User wwwrun erstellt die Session Datei, der Fehler tritt noch nicht auf. Besitzer der Datei ist wwwrun.
Wenn die Session nun wieder aufgenommen wird, dann kommt es zu dem Fehler, da wwwrun keine Schreibrechte hat, obwohl wwwrun der Owner ist.
Die Datei hat die Attribute ---r----x (Oktal 0041)
Woran kann es liegen, dass der Besitzer der Datei gar keine Rechte hat?
Wie gebe ich dem Benutzer wwwrun dauerhaft volle Zugriffsrechte auf sämtliche Inhalte des Session Ordners?
Den Pfad in der php.ini habe ich schon mehrfach angepasst, überall tritt das gleiche Problem auf


Kann mir jemand diesbezüglich helfen?

Viele Grüße, Micha
 
Last edited by a moderator:
Hallo,

ich bin der Programmierer. Der Wert session.save_path kann zwei Parameter erhalten, den Pfad und noch einen optionalen Integerwert, der die Subarchivebene bestimmt.
Wie kann man den Dateimodus dort angeben?
 
Ich finde es in der offiziellen Doku gerade auch nicht, aber es geht als mittlerer Parameter:
Code:
session.save_path=0;[COLOR="Blue"]666[/COLOR];"/tmp/"

huschi.
 
Nachtrag:
Gerade gefunden wo ich es gelesen habe: Als Kommentar in meiner php.ini.
Code:
; As of PHP 4.0.1, you can define the path as:
;
;     session.save_path = "N;/path"
;
; where N is an integer.  Instead of storing all the session files in
; /path, what this will do is use subdirectories N-levels deep, and
; store the session data in those directories.  This is useful if you
; or your OS have problems with lots of files in one directory, and is
; a more efficient layout for servers that handle lots of sessions.
;
; NOTE 1: PHP will not create this directory structure automatically.
;         You can use the script in the ext/session dir for that purpose.
; NOTE 2: See the section on garbage collection below if you choose to
;         use subdirectories for session storage
;
; The file storage module creates files using mode 600 by default.
; You can change that by using
;
;     session.save_path = "N;MODE;/path"
;
; where MODE is the octal representation of the mode. Note that this
; does not overwrite the process's umask.

huschi.
 
Code:
; The file storage module creates files [COLOR="Red"]using mode 600 by default[/COLOR].
...
; where MODE is the octal representation of the mode. Note that this
; [COLOR="Red"]does not overwrite the process's umask[/COLOR].
Ich denke nicht, dass das sein Problem behebt - den Grund meiner Annahme habe ich mal rot markiert.
 
Hallo,
auf dem Server wird dieser Parameter nicht erkannt, sondern als Teil des Pfades interpretiert: 777;/var/lib/php/session/...
Installiert ist PHP Version 4.3.10.
 
Kurze zwischenfrage:
Ist dir inzwischen bewusst, dass du bei der umask ansetzen solltest?
Hast du mal die Config von php und apache nach Umask-Settings abgegrast?
 
Last edited by a moderator:
Dann muß man halt mal *alle* Verzeichnisrechte prüfen.
Also:
Code:
ls -ld /var/
ls -ld /var/lib/
ls -ld /var/lib/php/
ls -ld /var/lib/php/session/
ls -l /var/lib/php/session/sess_*
Evtl. mal das session-Verzeichnis nach /tmp/ legen.

huschi.
 
Hallo,
ich habe nun die Verzeichnisrechte überprüft, folgendes Ergebnis:

755 ls -ld /var/
755 ls -ld /var/lib/
777 ls -ld /var/lib/php/
777 ls -ld /var/lib/php/session/
6114 ls -l /var/lib/php/session/sess_*

Wenn ich das Spiel nun starte, wird eine neue session im tmp ordner angelegt. Erzeugt von wwwrun, diese Datei hat 0041 als Rechte eingetragen. Wenn ich diese nun ändere auf 755, dann kann ich das Spiel fehlerfrei starten. Wenn ich das Spiel beende, und neu starte habe ich wieder den Ursprungsfehler und die Rechte stehen wieder auf 0041.

Hoffe das hilft weiter

Gruß Micha
 
755 ls -ld /var/
755 ls -ld /var/lib/
777 ls -ld /var/lib/php/
777 ls -ld /var/lib/php/session/
Das hat jetzt zwar nichts mit Ursache oder Lösung deines Problems zu tun, aber den Session-Pfad worldreadable zu machen, ist keine gute Idee.
Dort hat nur der User Zugriff zu haben, unter dem die Scripts laufen.

Du könntest mal versuchen, über ACL einen Zustand zu enforcen, der die Anwendung erstmal wieder laufen lässt:
Code:
setfacl -m d:m:rwx -m d:u:wwwrun:rwx /var/lib/php/session/
Damit sollten für alle neu angelegten Files per Default-ACL diese schreibbar sein. Ungeachtet der nativen Dateirechte.
Wenn das funktioniert, ist das aber _NICHT_ die Lösung deines Problems, sondern erstmal ein Workarround.
 
Hallo
und erst mal Danke für die schnelle Hilfe.
Ich würde gerne das Ursprungsproblem lösen. Ich habe jetzt folgenden Stand: Das Problem liegt an fehlenden Rechten für wwwrun. Es wird also eine tmp Datei von wwwrun erzeugt, welche die gleichen Rechte wie wwwrun erhält. Die sind aber so eingestellt, dass wwwrun nicht mehr darauf zugreifen kann. Es muss also das Ursrungsrecht für wwwrun verändert werden bzw. verändert worden sein, denn früher ging es ja wunderbar. Ich meine die Rechte sind in der Apache-configuration festgelegt. Dort gibt es eine httpd.conf entweder in der oder einer Unterdatei. Wenn in dieser Config Datei die Rechte anders festgelegt werden, dann müsste wwwrun doch wieder auf seine selbst erstellten Dateien zugreifen können.
Sehe ich das so richtig? Wenn ja, wie müsste die Config Datei abgeändert werden?

Viele Grüße vom Bodensee

Micha
 
Nein, nicht in der Apache-Conf. Wenn dann im PHP-Modul (also php.ini). Denn es ist ja nicht Apache, der die Session-Verwaltung macht, sondern PHP.
Außerdem gibt es keine Direktive für den Apache die so etwas könnte.
Die php.ini hab ich zwar schon durchgeschaut ohne was passendes für Dich zu finden (siehe oben; gilt nämlich erst ab PHP5), aber da weiß man ja nie genau...

Allerdings könnte es sein, daß Deine ACLs bereits verstellt worden sind. Denn daß Du setfacl überhaupt drauf hast ist etwas verwunderlich. Es wird nicht unbedingt std.-mässig installiert.
Es wäre evtl. interessant gewesen mit "getfacl" bzw. "setfacl -x" rumzuspielen.

huschi.
 
Denn daß Du setfacl überhaupt drauf hast ist etwas verwunderlich. Es wird nicht unbedingt std.-mässig installiert.
Diese Aussage bitte immer von der Dist abhängig machen. ACL gibt es nun nicht erst seit letztem Jahr und dürften sich langsam rumgesprochen haben.

Zudem dürfte das sein Problem nicht erklären können, da ACL zusätzlich zu den nativen Rechten gesetzt werden. Bei ihm sind aber gerade die nativen Dateirechte verbogen.
 
Hallo,
hab mal wieder lange gegoogelt und möchte nun versuchen über UMASK mein Problem zu lösen. Das ist zwar nicht die eigentliche Lösung des Problems, aber es würde vermutlich das ganze wieder zum laufen bringen, bis sich jemand den Server mal genauer ansieht.

Ich würde gerne UMASK 022 setzen, damit wwwrun wieder auf seine selbst erstellten Dateien zugreifen kann. Nur weiß ich nicht wo die bisherige UMASK festgelegt wird, damit ich das ändern kann.
Hat da jemand einen Tipp?

Viele Grüße

Micha
 
Back
Top