tmp-file permissions wechseln nach apache restart

[Anonymous]

Hallo,

habe da ein stranges Problem, welches gestern auf einmal aufgetaucht
ist und reproduzierbar auftritt.
Das System ist Debian-Sarge mit PHP als FastCGI und SuEXEC.

Bootet der Rechner neu, funktioniert alles, restartet man allerdings
den Apache (zb um config zu ändern), klappen die Sessions in PHP
nicht mehr. Es erscheint im Log:

Code: Select all

[Sun May 07 01:38:27 2006] [error] [client 1.2.3.4] FastCGI: server "/var/www/php-fcgi-scripts/example.de/php-fcgi-starter" stderr: PHP Warning:  session_start(): open(/tmp/sess_a9ce631794638de9b79ba89cbb30d82a, O_RDWR) failed: Permission denied (13) in /var/www/example.de/docs/blog/scripts/login.php on line 30
[Sun May 07 01:38:27 2006] [error] [client 1.2.3.4] FastCGI: server "/var/www/php-fcgi-scripts/example.de/php-fcgi-starter" stderr: PHP Warning:  Unknown(): open(/tmp/sess_a9ce631794638de9b79ba89cbb30d82a, O_RDWR) failed: Permission denied (13) in Unknown on line 0

Und in /tmp werden die files nicht so angelegt

Code: Select all

-rw-------   1 example_de example_de      0 2006-05-07 18:06 sess_f577d6b15998a1de4bc1e43dce31d4e4

sondern so:

Code: Select all

-r--------   1 example_de example_de      0 2006-05-07 18:06 sess_f577d6b15998a1de4bc1e43dce31d4e4

Die Kiste lief eigentlich Monate ohne Probleme und hatte auch keine
großen Änderungen erlebt. Deshalb stehe ich/wir vor einem Rätsel.

Einzige Änderung die uns einfällt, die aber (zurückgenommen) nichts
ändert: Umstellung auf openbase-dir in der php.ini.

Was wir uns auch noch dachten, ist vielleicht eine umask-änderung in der .bashrc des root, war aber nicht. Plattenplatz ist auch vorhanden...

Danke für Eure Hilfe.

[sledge0303]

Hmmm, Permission denied sagt eigentlich alles aber nach einem reboot des Servers tritt das nicht auf?
Prüfe mal nach reboot die errorlogs erneut oder hast einen unerbetenen Gast eingefangen?
Schau mal auf laufenden Prozesse!

[Anonymous]

Genau. Es tritt nur auf, wenn man Apache mit zb

Code: Select all

/etc/init.d/apache restart

neu startet. Nach einem Reboot jedoch ist alles i.o.

Permission denied sagt eigentlich alles

Naja schon logisch, wenn man sich die session files in /tmp
ankuckt, aber das war ja genau meine Frage.

Auf Besucher hab ich sonst auch keine Hinweise. Prozesse alles
io. Durchsatz nicht erhöht.

[sledge0303]

Moin,

einer unserer Programmierer hat mal eben über die Schulter geschaut beim lesen deiner Anfrage und sagte gleich, es hat sich anscheinend etwas in der Schreibberechtigung deines Skripts etwas geändert. Passiert das auch wenn du ein anderes Skript aufrufst?
Ungebetene Gäste sind aber trotzdem möglich, sowas in der Form hatte mal ein Kunde, dessen Rootie ich manage, da hatte jemand sich eingenistet und für eine globala Spamattacke vorbereitet.
Durch Zufall hatte er das Dingen dann entdeckt, auch nur weil er ein paar Zeilen im hijacked Skript ersetzen wollte...
Wenn ich auf meine Logs im Rootie schaue, wurden auch erfolgreich versuche unterbunden Skripte zu verändern.
Solche Einträge finde ich tagtäglich:

Code: Select all

70.84.200.2 - - [08/May/2006:05:40:25 +0200] "GET /adserver/adxmlrpc.php HTTP/1.0" 404 1052 "-" "-"
70.84.200.2 - - [08/May/2006:05:40:25 +0200] "GET /phpAdsNew/adxmlrpc.php HTTP/1.0" 404 1052 "-" "-"
70.84.200.2 - - [08/May/2006:05:40:27 +0200] "GET /phpadsnew/adxmlrpc.php HTTP/1.0" 404 1052 "-" "-"
70.84.200.2 - - [08/May/2006:05:40:27 +0200] "GET /phpads/adxmlrpc.php HTTP/1.0" 404 1052 "-" "-"
70.84.200.2 - - [08/May/2006:05:40:27 +0200] "GET /Ads/adxmlrpc.php HTTP/1.0" 404 1052 "-" "-"
70.84.200.2 - - [08/May/2006:05:40:28 +0200] "GET /ads/adxmlrpc.php HTTP/1.0" 404 1052 "-" "-"
70.84.200.2 - - [08/May/2006:05:40:28 +0200] "GET /xmlrpc.php HTTP/1.0" 404 1052 "-" "-"
70.84.200.2 - - [08/May/2006:05:40:29 +0200] "GET /xmlrpc/xmlrpc.php HTTP/1.0" 404 1052 "-" "-"

/phpmyadmin
/blog usw sind auch begehrte Ziele. Ist sowas bei dir auf dem Server gehostet bzw. du hast ein kleines Türchen drin...

Code: Select all

[Anonymous]

Schreibberechtigung deines Skripts etwas geändert

Das verstehe ich nur zur Hälfte. Klar hat sich was geändert, nur
was!??
Die Schreibrechte des Skripts denke ich nicht, die sind so wie sie
davor auch waren ...
Und ja es passiert bei allen Skripten, die -denke ich- session_start()
aufrufen, was ja im anlegen der /tmp/sess_???? files resultiert.

[Joe User]

Alle verfügbaren Updates eingespielt? Gäste?

[sledge0303]

Gäste?

ganz offensichtlich ein ungebetender Gast...

Das verstehe ich nur zur Hälfte. Klar hat sich was geändert, nur
was!??

Hoffentlich hast nicht rein zufällig einen neuen User bekommen mit bestimmten rechten?
Mal eine andere Frage, womit sicherst du den Server ab?
mod_security, Plesk etc?

[EDIT]
Sind deine Skripte noch im Originalzustand mit Rechte? Sind neue "hinzugekommen" die nicht kennst? Schau mal nach ob an irgendwelchen Skripten in der letzten Zeit sich was geändert hat...
[/EDIT]

[rootsvr]

Nachdem seine Kiste auch meine Kiste ist (und ich am WE weg war).

Es gibt (soweit ich das sehen kann) keine Gäste
- keine gefunden mit rkhunter oder chkrootkit
- keine neuen User
- keine Dateien in /tmp
- Einloggen geht nur über ssh, kein root login
- Auf der Maschine läuft nen Debian stable, Cyrus+Postfix,amavis,Apache2 nach Howto von hier, Squirrelmail, statisches Awstats, + eine Handvoll virtueller Hosts, die hoffentlich alle hübsch in ihren openbasedirs bleiben..

Warum jetzt auf einmal die Rechte (nur von angelegten Session files aller Domains) falsch sind ist noch offen. nen Unbekannten Besucher vermute ich zZ eher nicht, da würden wir noch andere Sachen sehen, z.B. Traffic, Spam o.ä.

[Roger Wilco]

Was wir uns auch noch dachten, ist vielleicht eine umask-änderung in der .bashrc des root, war aber nicht. Plattenplatz ist auch vorhanden...

Rein interessehalber, was gibt bei dir denn folgendes Skript aus?

Code: Select all

<?php printf("%03on", umask()); ?>

Wie sieht dein /var/www/php-fcgi-scripts/example.de/php-fcgi-starter aus? Was steht in der php.ini in session.save_path? Welche rechte sind auf /usr/sbin/suexec2 gesetzt?

[rootsvr]

Rein interessehalber, was gibt bei dir denn folgendes Skript aus?

Code: Select all

<?php printf("%03on", umask()); ?>

Als root auf der Shell:
222
Als Webuser:
022

Wie sieht dein /var/www/php-fcgi-scripts/example.de/php-fcgi-starter aus?

Code: Select all

Eine Domain:
#!/bin/sh
PHPRC="/var/www/example.de/conf"
export PHPRC
PHP_FCGI_CHILDREN=4
export PHP_FCGI_CHILDREN
exec /home/webmaster/php/bin/php-fcgi

Was steht in der php.ini in session.save_path?

; session.save_path =

Welche rechte sind auf /usr/sbin/suexec2 gesetzt?

# ll /usr/lib/apache2/
insgesamt 36
drwxr-xr-x 3 root root 4096 2006-01-21 16:52 .
drwxr-xr-x 46 root root 16384 2006-05-08 18:16 ..
drwxr-xr-x 2 root root 4096 2006-01-21 16:52 modules
-rwsr-x--- 1 root www-data 10596 2005-09-05 13:16 suexec

[rootsvr]

Nach einem restart des apaches gibt das php snipplet auch für den Webuser 222 aus..

[Joe User]

Nach einem restart des apaches gibt das php snipplet auch für den Webuser 222 aus..

Logisch, denn er läuft dann auch als root, vgl. phpinfo()...

[rootsvr]

Args..
danke für die tomaten wegnehmen..

in der .bashrc stand für root 0222 statt 022

nu gehts wieder.