Kein Grund, sowohl / run als auch / tmp zu haben
Ich denke, du hast recht. /tmpist im Wesentlichen veraltet, jetzt haben wir /run. Wenn Ihr Programm dazu in der Lage ist (was erfordert, dass es als privilegierte Operation installiert wurde ), würden Sie heutzutage ein Unterverzeichnis von verwenden /run. Dies ist aus Sicherheitsgründen.
Beispielsweise wird der CUPS-Druckerdämon nicht als Root ausgeführt, sondern in der Regel von einem Betriebssystempaket installiert. Das Paket wird installiert /usr/lib/tmpfiles.d/cups.confund systemd-tmpfileserstellt ein Verzeichnis, auf das es zugreifen kann. Da sich das Verzeichnis unter befindet /run, kann der Name nicht böswillig von einem nicht privilegierten Benutzer behauptet worden sein, im Gegensatz zu /tmpdem, der von der Welt beschreibbar ist.
"Unprivilegierte Programme", die nicht /rundirekt verwendet werden können
Der eigentliche Unterschied besteht darin, ob Ihr Programm von einem beliebigen, nicht privilegierten Benutzer unter seiner eigenen Benutzer-ID ausgeführt wird. Im Allgemeinen möchten Sie es jedoch nicht verwenden /tmp, da andere nicht privilegierte Benutzer darauf zugreifen können. Sie würden es vorziehen, zu verwenden $XDG_RUNTIME_DIR. In der Regel wird dies implementiert als /run/user/$(id -u)- so dass es zufällig auch ein Unterverzeichnis von ist /run. Die Lage ist jedoch nicht garantiert. Programme sollten immer die Umgebungsvariable verwenden.
/tmpwäre nur für die Ad-hoc-Zusammenarbeit zwischen verschiedenen nichtprivilegierten Benutzern auf dem System nützlich. Solche Ad-hoc-Systeme sind anfällig für einen böswilligen Benutzer, der sich weigert, zusammenzuarbeiten, und verwöhnt Dinge für alle :). Ein Beispiel wären nicht privilegierte Benutzer, die sich dafür entscheiden, eine Version des talkDaemons unter Verwendung eines Unix-Sockets auszuführen .
Hinweis: In der nachstehenden Prüfliste von Pöttering wurde angegeben, dass /tmpdies für "kleine Dateien" nützlich ist, wohingegen diese /runnur für "Kommunikationsprimitive" verwendet werden sollten. Ich glaube auch nicht, dass diese Unterscheidung wahr ist. Der Aushängeschild für /runist udev, und ich bin mir ziemlich sicher, /run/udeventhält interne Datenbanken. Wenn Sie ein /runVerzeichnis haben, möchte wohl niemand der behaupteten Unterscheidung folgen und ein anderes Verzeichnis erstellen , um Unordnung zu schaffen /tmp. In der Praxis verwenden wir /runheutzutage nur.
Die Verwendung von weltweit beschreibbaren freigegebenen Namespaces [wie / tmp] für Kommunikationszwecke war immer problematisch, da zum Aufbau der Kommunikation stabile Namen erforderlich sind, stabile Namen jedoch die Türen für DoS-Angriffe öffnen. Dies kann teilweise korrigiert werden, indem für bestimmte Dienste während des frühen Startvorgangs geschützte Verzeichnisse pro App eingerichtet werden (wie dies bei X11 der Fall ist). Dies behebt das Problem jedoch nur teilweise, da dies nur dann ordnungsgemäß funktioniert, wenn auf jede Paketinstallation ein Neustart folgt.
...
Eine andere Fedora-Funktion (für Fedora 17) hat die Semantik von / tmp für viele Systemdienste geändert, um sie sicherer zu machen, indem die / tmp-Namespaces der verschiedenen Dienste isoliert wurden
...
Da / tmp nicht mehr unbedingt ein gemeinsam genutzter Namespace ist, ist es im Allgemeinen nicht als Speicherort für Kommunikationsprimitive geeignet.
...
[/ run] ist garantiert ein tmpfs und wird daher beim Booten automatisch gespült. Darüber hinaus wird keine automatische Bereinigung durchgeführt.
...
Hier ist eine grobe Anleitung, wie wir Ihnen (einem Linux-Anwendungsentwickler) vorschlagen, das richtige Verzeichnis auszuwählen:
- Sie benötigen einen Ort, an dem Sie Ihren Socket (oder ein anderes Kommunikationsprimitiv) platzieren können, und Ihr Code wird privilegiert ausgeführt: Verwenden Sie ein Unterverzeichnis unter / run. (Oder unter / var / run für zusätzliche Kompatibilität.)
- Sie benötigen einen Speicherort für Ihren Socket (oder ein anderes primitives Kommunikationselement), und Ihr Code wird nicht privilegiert ausgeführt: Verwenden Sie ein Unterverzeichnis unter $ XDG_RUNTIME_DIR.
- Sie benötigen einen Ort, an dem Sie größere Downloads und Downloads durchführen und ohne Berechtigungen ausführen können: Verwenden Sie $ XDG_DOWNLOAD_DIR.
- Sie benötigen einen Ort, an dem Sie Cachedateien ablegen können, die persistent und nicht privilegiert sein sollten: Verwenden Sie $ XDG_CACHE_HOME.
- Nichts von alledem trifft zu und Sie müssen eine kleine Datei platzieren, die keine Persistenz benötigt: Verwenden Sie $ TMPDIR mit einem Fallback auf / tmp. Und benutze mkstemp () und mkdtemp () und nichts Eigenes.
- Verwenden Sie andernfalls $ TMPDIR mit einem Fallback auf / var / tmp. Verwenden Sie auch mkstemp () / mkdtemp ().
Beachten Sie, dass diese Regeln nur von uns vorgeschlagen werden. Diese Regeln berücksichtigen alles, was wir über dieses Thema wissen, und vermeiden Probleme mit aktuellen und zukünftigen Distributionen, soweit wir sie sehen können. Bitte denken Sie daran, Ihre Projekte zu aktualisieren, um diese Regeln zu befolgen, und denken Sie daran, wenn Sie neuen Code schreiben.
Eine Sache, die wir hervorheben möchten, ist, dass / tmp und / var / tmp häufig nicht die richtige Wahl für Ihren Anwendungsfall sind. Es gibt gültige Verwendungen dieser Verzeichnisse, aber oft ist ein anderes Verzeichnis tatsächlich der bessere Ort. Denken Sie also über die anderen Optionen nach. Wenn Sie sich jedoch für / tmp oder / var / tmp entscheiden, müssen Sie mindestens mkstemp () / mkdtemp () verwenden.
Wir kommen irgendwie mit dem alten /tmpSockel davon, der vom X-Window-System verwendet wird, wie oben beschrieben. Ich habe falsch verstanden tmpfiles.d/x11.conf. Sieht eher nach Kooperation aus :). Ich gehe davon aus, dass der Code geprüft wurde, sodass Denial-of-Service das Schlimmste ist, was passieren kann.