Benutzer und Rechte von /tmp

[MacFlieger]

Heute mal eine besonders ungewöhnliche Frage:

Wie sehen bei euch die Rechte und Besitzverhältnisse von /tmp aus?
Bei mir:
ich staff rwxr-xr-x (ich ist mein Username)
Komisch finde ich, daß dieser zentrale Ordner mir als Nicht-Admin gehört und nur ich darin Schreibrechte habe.

Warum ich darauf komme? Ich will gerade mal wieder was programmieren, da meckert PHP, daß es die Sessiondatei nicht schreiben darf:
"Warning: session_start(): open(/tmp/sess_2824ab07471cb7bf47edc3eff5d5b30a, O_RDWR) failed: Permission denied (13)"
Komisch. Sonst ging das ohne Probleme.

Auch eine Rechtereparatur brachte keine Änderung.

[mbs]

Normalerweise sollte es keinen "realen" Ordner /tmp geben, sondern /tmp ist ein symbolischer Link auf
den relativen Pfad private/tmp.

Die Rechte von /private/tmp sollten auf 01777 stehen, Eigentümer root, Gruppe wheel.

Auch eine Rechtereparatur brachte keine Änderung.

Das ist mir in anderen Fällen auch schon aufgefallen. Das Reparaturprogramm kann leider die Rechte von /tmp nicht reparieren. Ist möglicherweise aber auch knifflig, da das Programm /tmp selbst braucht...

[MacFlieger]

Normalerweise sollte es keinen "realen" Ordner /tmp geben, sondern /tmp ist ein symbolischer Link auf
den relativen Pfad private/tmp.

/tmp ist bei mir definitiv ein relaer Ordner und kein symbolischer Link.
/private/tmp gibt es zusätzlich.

Die Rechte von /private/tmp sollten auf 01777 stehen, Eigentümer root, Gruppe wheel.

Für /private/tmp sind die Werte auch so.
Soll ich es wagen /tmp zu löschen und einen entsprechenden smybolischen Link auf /private/tmp zu setzen?
Hat so ein symbolischer Link auch Benutzer und Rechte, und wenn ja welche sind korrekt?

Schon mal danke für die Antwort.

[mbs]

Ja, dabei kann nicht viel passieren, es sei denn, Du hast gerade wichtige Programme laufen, die intensiv /tmp verwenden. Mach einfach ein

cd /
sudo rm -R /tmp
sudo ln -s private/tmp /tmp

Die Berechtigung des Links müsste danach automatisch auf rwxr-xr-x root:admin stehen.

Wäre jetzt interessant zu wissen, welches Programm das geändert hat. Ich glaube in alten Versionen von Mac OS X war /tmp auch mal anders. Ist das System upgegradet?  Aber wenn das Sticky-Bit (t) von /tmp schon nicht gesetzt ist, dann würde ich vermuten, irgendein Drittanbieter-Programm hat da rumgepfuscht...

[MacFlieger]

Ok, hat funktioniert und alles läuft wieder.

Das war, wie ich vermutet hatte, die Ursache für den PHP-Fehler. Auch der W3C-Validator, den ich hier lokal laufen habe, funktionierte auf einmal nicht mehr.

Das System ist auf meinem iMac G5. Ausgeliefert wurde der mit Tiger. Ich gehe stark davon aus, daß ich den trotzdem einmal neu installiert habe, ich weiß es aber nicht sicher. Das mache ich normalerweise immer, damit ich nicht so einen Unsinn wie Office X Testdrive und andere englische Programme drauf habe, die ich nie benötige. Auch der Migrationsassistent wurde nicht benutzt.
Auf jeden Fall war es kein upgegradetes System und es hatte ja alles funktioniert. Mir fiel das nur gestern auf, als plötzlich PHP keine Daten in /tmp schreiben konnte. Vor einiger Zeit ging das und der Validator definitiv noch.

Das Änderungsdatum von /private/tmp war der 20.4.2006, der älteste Eintrag in /tmp war vom 24.4.2006. Irgendwann dazwischen muß es passiert sein. Ich bin mir nicht sicher, was ich da alles gemacht habe , aber dazwischen lag auf jeden Fall die Inbetriebnahme des Visor und mehrfache Installation der Palm Desktop Software mit unterschiedlichster Versionsnummer bis das lief. Ich habe da ein wenig den Installer von Palm Desktop in Verdacht...

Danke für die Hilfe.