Posté par gouttegd .
En réponse au message Socket.
Évalué à 3.
et qu'ils doivent pouvoir utiliser les droits UGO ou numériques 755 par exemple pour gérer qui peut lire/ecrire dedans
À ce sujet, il faut noter que la page de manuel de unix(7) sous GNU/Linux semble erronée. Elle indique que la prise en compte des permissions de fichier sur la socket ne serait pas spécifiée par POSIX et qu’un programme portable ne devrait pas compter dessus ("POSIX does not make any statement about the effect of the permissions on a socket file, and on some systems, the socket permissions are ignored. Portable programs should not rely on this feature for security.").
Cela semble clairement faux car le standard POSIX indique bien que les fonctions qui écrivent sur des sockets renvoient EACCES en cas de défaut de droit d’écriture sur la socket. Une rapide vérification montre que tous les *BSD modernes (e.g. Free-, Net-, Open-BSD) par exemple implémentent ce comportement, pas seulement GNU/Linux.
J'ai l'impression qu'en général les socket Unix sont plus souvent utilisé pour ce logiciel mais je ne saurais dire pourquoi :/
Une autre raison possible est que pour des communications strictement locales, les sockets Unix sont plus performantes, au moins en principe (dans les faits je ne suis pas certain que la différence soit réellement notable, à moins que le volume des communications ne soit particulièrement élevé).
En effet, sur la plupart des systèmes, les messages échangés à travers une socket AF_INET passent à travers toute la pile réseau, avec tout l’overhead que ça implique : même dans le cas où la socket n’est liée qu’à une adresse locale (et donc jamais en contact avec un « vrai » réseau), il n’y a pas de chemin privilégié qui autoriserait à « court-circuiter » la pile réseau.
À l’inverse, les messages échangés à travers une socket Unix ont un chemin beaucoup plus simple.
[^] # Re: Sockets UNIX?
Posté par gouttegd . En réponse au message Socket. Évalué à 3.
À ce sujet, il faut noter que la page de manuel de unix(7) sous GNU/Linux semble erronée. Elle indique que la prise en compte des permissions de fichier sur la socket ne serait pas spécifiée par POSIX et qu’un programme portable ne devrait pas compter dessus ("POSIX does not make any statement about the effect of the permissions on a socket file, and on some systems, the socket permissions are ignored. Portable programs should not rely on this feature for security.").
Cela semble clairement faux car le standard POSIX indique bien que les fonctions qui écrivent sur des sockets renvoient EACCES en cas de défaut de droit d’écriture sur la socket. Une rapide vérification montre que tous les *BSD modernes (e.g. Free-, Net-, Open-BSD) par exemple implémentent ce comportement, pas seulement GNU/Linux.
Une autre raison possible est que pour des communications strictement locales, les sockets Unix sont plus performantes, au moins en principe (dans les faits je ne suis pas certain que la différence soit réellement notable, à moins que le volume des communications ne soit particulièrement élevé).
En effet, sur la plupart des systèmes, les messages échangés à travers une socket AF_INET passent à travers toute la pile réseau, avec tout l’overhead que ça implique : même dans le cas où la socket n’est liée qu’à une adresse locale (et donc jamais en contact avec un « vrai » réseau), il n’y a pas de chemin privilégié qui autoriserait à « court-circuiter » la pile réseau.
À l’inverse, les messages échangés à travers une socket Unix ont un chemin beaucoup plus simple.