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 lsof
tout 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?
filenames
socket
limit
unix-sockets
WhiteWinterWolf
la source
la source
Réponses:
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()
etstrncpy()
.Michael Kerrisk explique dans son livre à la page 1165 - Chapitre 57, Sockets: domaine Unix:
Les gars de Docker s'en sont même moqués, car certains sockets comptaient 110 caractères:
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:
Citant la réponse:
Autres systèmes d'exploitation (sockets de domaine Unix):
la source
./my.socket
ci-dessous répertoireA/
et un autre fichier socket également nommé./my.socket
ci-dessous répertoireB/
)?lsof
ne fait aucune distinction entre les deux fichiers socket, mais il semble toujours fonctionner mais je me demande si c'est juste parce que j'ai de la chance. Ce serait une bonne solution de contournement pour créer des fichiers socket sous un chemin qui est déjà plus long que la taille autorisée.lsof -U| grep amavis
(amavis-se 2708 zimbra 17u unix 0xffff8806c0a95400 0t0 310330411 /opt/zimbra/data/tmp/amavisd-zmq.sock
/tmp
avec des tonnes de répertoires non supprimés nommés de manière unique chacun contenant un seul fichier socket (tout à fait laid, mais portable et sécurisé).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:
socat
vous utilisez une commande telle que: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.
la source