Idiomatischer Speicherort für dateibasierte Sockets auf Debian-Systemen

Ich schreibe einen Daemon-Prozess für ein Debian-System C, das einen Unix Domain Socket verwendet .

Wenn das Arbeitsverzeichnis des Daemon-Prozesses das Stammverzeichnis ist, gibt es ein idiomatisches Verzeichnis, um den Socket im Dateisystem zu platzieren?

Sie sind üblicherweise in /tmpoder einem Unterverzeichnis davon zu finden. Beachten Sie, dass alles in /tmpbeim Herunterfahren gelöscht werden muss - nicht, dass es unbedingt gelöscht werden muss. Achten Sie jedoch darauf , dass dies möglich ist. Wenn Sie dies verwenden, überprüfen Sie, ob Sie jedes Mal Ihr Unterverzeichnis erstellen müssen. Sie sollten ein Unterverzeichnis verwenden, wenn Sie den Zugriff über Berechtigungen einschränken möchten, da dies /tmpweltweit lesbar ist.

/runund /var/run(die möglicherweise miteinander verknüpft sind) werden auf ähnliche Weise verwendet, aber sie werden im Allgemeinen als tmpfs-Dateisysteme bereitgestellt. Dies bedeutet, dass sie beim Booten erstellt werden und sich im Speicher befinden , nicht auf der Festplatte (verwenden Sie diese also nicht als Speicherort reichliche Datenmengen). Für einen Laufzeitsocket ist dies wahrscheinlich eine gute Wahl.

Beachten Sie, dass /runund alle anderen hier genannten Verzeichnisse außer /tmp mit root nur beschreibbar sind. Für einen Systemprozess ist dies in Ordnung. Wenn die Anwendung jedoch von einem nicht privilegierten Benutzer ausgeführt wird, möchten Sie entweder /tmpirgendwo ein permanentes Verzeichnis verwenden oder erstellen und Berechtigungen dafür festlegen oder einen Speicherort im $ HOME des Benutzers verwenden.

Es ist möglich, während der Installation ein Verzeichnis in /usr/share(oder /usr/local/share) zu erstellen . Verzeichnisse und Inhalte werden dort möglicherweise nicht wie in /tmpoder über Boot geerntet /run. Wie Jordanm in den Kommentaren hervorhebt , /usrkann es jedoch schreibgeschützt gemountet werden, und die Richtlinien für die Hierarchie des Linux-Dateisystems spiegeln dies wider . Natürlich kann es nicht schreibgeschützt sein, wenn Ihre Anwendung installiert ist. Wenn Sie also dort einen Socket erstellen möchten, können Sie ihn verlassen und später verwenden (Sie können trotzdem auf den Socket schreiben, obwohl der Datei ist schreibgeschützt).

Wenn Sie einen dauerhaften Ort zwischen Booten wünschen, der nicht schreibgeschützt gemountet wird, /etcist dies eine ziemlich sichere Sache, da dies häufig für systemweite Konfigurationen und Neukonfigurationen verwendet wird. OTOH, es ist möglich, Systeme zu haben, auf denen das dem gesamten Root-Dateisystem zugrunde liegende Gerät schreibgeschützt ist (z. B. eingebettete Systeme), mit / tmp und / auf einem anderen Gerät (wahrscheinlich: tmpfs im Speicher). Die zwei robustesten Strategien scheinen also zu sein:

• Installieren Sie den Socket an einem festen Ort, wenn die Anwendung installiert wird.

• Erstellen Sie ein Verzeichnis in /runoder /var/runzur Laufzeit und legen Sie den Socket dort ab.

• Mach das gleiche nur in /tmp.

Der Vorteil des ersten ist, dass Sie nach der Installation der App unabhängig davon einen Socket verwenden können. Der Vorteil des zweiten ist, dass es der vernünftigen Programmierung förderlicher sein kann . Der Vorteil des dritten ist, dass keine Superuser-Berechtigungen erforderlich sind. Es sollte einfach sein, von einer Implementierung zur anderen zu wechseln, wenn Sie später Ihre Meinung ändern.

Schließlich sollten Sie, wie BatchyX ansprach , zumindest eine Konfigurationsoption dafür anbieten und auf Ihre Standardauswahl zurückgreifen.