Pourquoi la longueur du chemin de socket est-elle limitée à une centaine de caractères?

Sur les systèmes Unix, les noms de chemin n'ont généralement pratiquement aucune limitation de longueur (enfin, 4096 caractères sous Linux) ... à l'exception des chemins de fichiers socket qui sont limités à environ 100 caractères (107 caractères sous Linux ).

• Première question: pourquoi une si faible limitation?

J'ai vérifié qu'il semble possible de contourner cette limitation en changeant le répertoire de travail actuel et en créant dans divers répertoires plusieurs fichiers socket utilisant tous le même chemin ./myfile.sock: les applications clientes semblent se connecter correctement aux processus serveur attendus même si lsoftout montre d'entre eux écoutant sur le même chemin de fichier socket.

• Cette solution de contournement est-elle fiable ou ai-je simplement eu de la chance?
• Ce comportement est-il spécifique à Linux ou cette solution de contournement peut-elle également s'appliquer à d'autres Unix?

Compatibilité avec d'autres plates-formes ou compatibilité avec des éléments plus anciens pour éviter les dépassements lors de l'utilisation de snprintf()et strncpy().

Michael Kerrisk explique dans son livre à la page 1165 - Chapitre 57, Sockets: domaine Unix:

SUSv3 ne spécifie pas la taille du champ sun_path. Les premières implémentations BSD utilisaient 108 et 104 octets, et une implémentation contemporaine (HP-UX 11) utilise 92 octets. Les applications portables doivent coder sur cette valeur inférieure et utiliser snprintf () ou strncpy () pour éviter les dépassements de tampon lors de l'écriture dans ce champ.

Les gars de Docker s'en sont même moqués, car certains sockets comptaient 110 caractères:

• lol 108 caractères ETOOMANY

C'est pourquoi LINUX utilise une prise de 108 caractères. Cela pourrait-il être changé? Bien sûr. Et c'est la raison pour laquelle, en premier lieu, cette limitation a été créée sur les anciens systèmes d'exploitation:

• Pourquoi la longueur de chemin maximale est-elle autorisée pour les sockets unix sur Linux 108?

Citant la réponse:

Il devait correspondre à l'espace disponible dans une structure de données de noyau pratique.

Citant «La conception et la mise en œuvre du système d'exploitation 4.4BSD» par McKusick et. Al. (page 369):

Les fonctions de gestion de la mémoire tournent autour d'une structure de données appelée mbuf. Les Mbufs, ou tampons de mémoire, ont une longueur de 128 octets, 100 ou 108 octets de cet espace étant réservés au stockage de données.

Autres systèmes d'exploitation (sockets de domaine Unix):

• OpenBSD : 104 caractères
• FreeBSD : 104 caractères
• Mac OS X 10.9 : 104 caractères

Concernant le pourquoi, nwildner a déjà écrit une excellente réponse .

Ici, je vais me concentrer uniquement sur le comment et l'utilisation relative du chemin.

En interne, bien que le fichier socket puisse également être recherché par son nom (je suppose), il est généralement recherché par inode. Sous Linux, cette recherche est assurée par la fonction unix_find_socket_byinode()définie dans net / unix / af_unix.c .

Cela peut être facilement vérifié comme suit:

• Créez deux répertoires A / et B / .
• Sous chaque répertoire, faites un processus d'écoute sur les fichiers socket portant le même nom. Avec socatvous utilisez une commande telle que:

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

• Échangez maintenant les fichiers socket en déplaçant A / my.sock vers B / et vice-versa.
• Désormais, si l'application cliente se connecte à A / my.sock, elle contactera le serveur B et si elle se connecte à B / my.sock, elle contactera le serveur A (notez cependant que lorsque la communication se termine, le processus serveur peut supprimer légitimement ce qu'il pense être son propre fichier socket).

J'ai vérifié ce comportement sur une poignée de systèmes Unix (Linux Debian, FreeBSD et OpenIndiana pour obtenir une certaine diversité), donc ce comportement semble être au moins très répandu, sinon standard.

Les chemins absolus sont généralement utilisés comme convention entre le client et les processus serveur, car le processus client peut autrement ne pas savoir comment établir la communication initiale avec le serveur.

Cependant, si cette communication initiale n'est pas un problème, il semble donc sûr d'utiliser des chemins relatifs pour la création de fichiers socket, ce qui permet d'éviter les problèmes de longueur de chemin lorsque l'emplacement du fichier socket n'est pas directement contrôlé par le processus serveur.