Warum ist die Socket-Pfadlänge auf hundert Zeichen begrenzt?

Question

Auf Unix-Systemen haben Pfadnamen normalerweise praktisch keine Längenbeschränkung (also 4096 Zeichen unter Linux)... mit Ausnahme von Socket-Dateipfaden, die beschränkt sind aufca. 100 Zeichen(107 Zeichen aufLinux).

• Erste Frage:warum so eine geringe Beschränkung?

Ich habe überprüft, dass es möglich scheint, diese Einschränkung zu umgehen, indem man das aktuelle Arbeitsverzeichnis ändert und in verschiedenen Verzeichnissen mehrere Socket-Dateien erstellt, die alle denselben Pfad verwenden ./myfile.sock: Die Client-Anwendungen scheinen eine korrekte Verbindung zu den erwarteten Serverprozessen herzustellen, obwohl lsofangezeigt wird, dass sie alle auf demselben Socket-Dateipfad lauschen.

• Ist dieser Workaround zuverlässig oder hatte ich einfach nur Glück?
• Ist dieses Verhalten spezifisch für Linux oder kann dieser Workaround auch auf andere Unix-Versionen angewendet werden?

Answer 1

Kompatibilität mit anderen Plattformen oder Kompatibilität mit älteren Sachen, um Überläufe bei der Verwendung von snprintf()und zu vermeiden strncpy().

Michael Kerrisk erklärt insein BuchBei derSeite 1165- Kapitel 57, Sockets: Unix-Domäne:

SUSv3 gibt die Größe des Felds sun_path nicht an. Frühe BSD-Implementierungen verwendeten 108 und 104 Bytes, und eine aktuelle Implementierung (HP-UX 11) verwendet 92 Bytes. Portable Anwendungen sollten mit diesem niedrigeren Wert codieren und snprintf() oder strncpy() verwenden, um Pufferüberläufe beim Schreiben in dieses Feld zu vermeiden.

Die Docker-Leute haben sich sogar darüber lustig gemacht, weil einige Sockets 110 Zeichen lang waren:

• lol, 108 Zeichen, ETOOMANY

Aus diesem Grund verwendet LINUX einen 108-Zeichen-Socket. Könnte man das ändern? Natürlich. Und das ist der Grund, warum diese Einschränkung überhaupt erst bei älteren Betriebssystemen eingeführt wurde:

• Warum ist für Unix-Sockets unter Linux 108 eine maximal zulässige Pfadlänge zulässig?

Zitat aus der Antwort:

Es sollte dem verfügbaren Speicherplatz in einer praktischen Kernel-Datenstruktur entsprechen.

Zitat aus „The Design and Implementation of the 4.4BSD Operating System“ von McKusick et. al. (Seite 369):

Die Speicherverwaltungsfunktionen basieren auf einer Datenstruktur namens mbuf. Mbufs oder Speicherpuffer sind 128 Byte lang, wobei 100 oder 108 Byte dieses Speicherplatzes für die Datenspeicherung reserviert sind.

Andere Betriebssysteme (Unix-Domain-Sockets):

• OpenBSD: 104 Zeichen
• FreeBSD: 104 Zeichen
• Mac OS X 10.9: 104 Zeichen

Answer 2

Zum Warum hat nwildner bereits einenausgezeichnete Antwort.

Hier werde ich mich nur auf das Wie und die relative Pfadnutzung konzentrieren.

Intern können Socket-Dateien zwar auch nach Namen gesucht werden (denke ich), aber normalerweise werden sie nach Inode gesucht. Unter Linux wird diese Suche durch die unix_find_socket_byinode()in definierte Funktion sichergestellt.net/unix/af_unix.c.

Dies lässt sich ganz einfach wie folgt überprüfen:

• Erstellen Sie zwei VerzeichnisseA/UndB/.
• Lassen Sie in jedem Verzeichnis einen Prozess auf Socket-Dateien mit demselben Namen lauschen. MitsocatSie würden einen Befehl wie den folgenden verwenden:

$ socat UNIX-LISTEN:./my.sock -

• Tauschen Sie nun die Socket-Dateien aus, indem Sie sie verschiebenA/meine.SockeZuB/und umgekehrt.
• Wenn sich die Client-Anwendung ab sofort mitA/meine.SockeEs wird den Server kontaktierenBund wenn es eine Verbindung zuB/meine.SockeEs wird den Server kontaktierenA(Beachten Sie jedoch, dass der Serverprozess nach Beendigung der Kommunikation möglicherweise seine eigene Socket-Datei löscht.)

Ich habe dieses Verhalten auf einer Handvoll Unix-Systemen (Linux, Debian, FreeBSD und OpenIndiana, um etwas Abwechslung zu bieten) überprüft. Daher scheint dieses Verhalten zumindest weit verbreitet, wenn nicht sogar Standard zu sein.

Absolute Pfade werden üblicherweise als Konvention zwischen den Client- und Serverprozessen verwendet, da der Clientprozess sonst möglicherweise nicht weiß, wie er die anfängliche Kommunikation mit dem Server herstellen soll.

Wenn diese anfängliche Kommunikation jedoch kein Problem darstellt, erscheint es sicher, relative Pfade für die Erstellung von Socket-Dateien zu verwenden. Dadurch können Probleme mit der Pfadlänge vermieden werden, wenn der Speicherort der Socket-Datei nicht direkt vom Serverprozess gesteuert wird.