unix
Sockets pour communications locales entre processus
- Provided by: manpages-fr (Version: 3.65d1p1-1)
- Report a bug
Sockets pour communications locales entre processus
#include <sys/socket.h>
#include <sys/un.h>
unix_socket = socket(AF_UNIX, type, 0);
error = socketpair(AF_UNIX, type, 0, int *sv);
La famille de socket AF_UNIX (aussi connue sous le nom AF_LOCAL) sert à communiquer efficacement entre processus sur la même machine. Traditionnellement, les sockets de domaine UNIX peuvent ne pas être nommées ou bien être liées à un chemin d'accès, lequel sera marqué comme étant de type socket, sur un système de fichiers. Linux gère également un espace de noms abstrait, indépendant du système de fichiers.
Les types valables sont : SOCK_STREAM, pour une socket orientée flux et SOCK_DGRAM, pour une socket orientée datagramme, préservant les limites entre messages (comme sur la plupart des implémentations UNIX, les sockets datagramme de domaine UNIX sont toujours fiables et ne réordonnent pas les datagrammes) ; et (depuis Linux 2.6.4) SOCK_SEQPACKET, pour une socket orientée connexion, préservant les limites entre messages et délivrant les messages dans l'ordre où ils ont été envoyés.
Les sockets de domaine UNIX prennent en charge la transmission de descripteurs de fichier ou d'identificateurs d'un processus à l'autre en utilisant des données annexes.
Une adresse de socket de domaine UNIX est
représentée dans la structure suivante :
#define UNIX_PATH_MAX 108
struct sockaddr_un {
sa_family_t sun_family; /* AF_UNIX */
char sun_path[UNIX_PATH_MAX]; /* chemin accès */
};
sun_family contient toujours la valeur AF_UNIX.
On considère trois types d'adresse pour cette structure :
offsetof(struct sockaddr_un, sun_path) + strlen(sun_path) + 1
et sun_path contient une chaîne de caractères, terminée par un octet nul, représentant le chemin d'accès.
Pour des raisons historiques, les options de ces sockets sont indiquées avec un type SOL_SOCKET même si elles sont spécifiques AF_UNIX. Elles peuvent être définies avec setsockopt(2) et lues avec getsockopt(2) en indiquant la famille SOL_SOCKET.
Si un appel bind(2) indique addrlen comme sizeof(sa_family_t), ou si l'option de socket SO_PASSCRED était indiquée pour une socket qui n'était pas liée explicitement à une adresse, alors la socket est autoliée à une adresse abstraite. L'adresse est constitué d'un octet nul suivi par cinq octets de l'ensemble de caractères [0-9a-f]. Le nombre d'adresses autoliées est donc limité à 2^20 (à partir de Linux 2.1.15, quand la fonctionnalité d'autolien a été ajoutée, huit octets étaient utilisés, et le nombre d'adresses autoliées était donc limité à 2^32. La modification à cinq octets est intervenue avec Linux 2.3.15).
Les paragraphes suivants décrivent des détails spécifiques au domaine UNIX, et des fonctionnalités de l'API des sockets du domaine UNIX non prises en charge sous Linux.
Les sockets de domaine UNIX ne prennent pas en charge la notion de données hors-bande (l'attribut MSG_OOB de send(2) et recv(2)).
L'attribut MSG_MORE de send(2) n'est pas pris en charge sur les sockets de domaine UNIX.
L'utilisation de MSG_TRUNC dans la paramètre flags de recv(2) n'est pas prise en charge sur les sockets de domaine UNIX.
L'option SO_SNDBUF a un effet pour les sockets de domaine UNIX, mais SO_RCVBUF n'en a pas. Pour les sockets datagramme, la valeur SO_SNDBUF impose une limite supérieure à la taille des datagrammes sortants. Cette limite est calculée comme le double de la valeur de l'option, moins 32 octets utilisés par le système (consultez socket(7)).
Les données annexes sont envoyées et reçues en utilisant sendmsg(2) et recvmsg(2). Pour des raisons historiques, les messages annexes listés ci-dessous sont indiqués avec un type SOL_SOCKET même s'ils sont spécifiques AF_UNIX. Pour les envoyer, définissez le champ cmsg_level de la structure cmsghdr à SOL_SOCKET et le champ cmsg_type avec le type du message. Pour plus de détails, consultez cmsg(3).
struct ucred {
pid_t pid; /* PID processus émetteur */
uid_t uid; /* UID processus émetteur */
gid_t gid; /* GID processus émetteur */
};
Depuis la glibc 2.8, la macro de test de fonctionnalités _GNU_SOURCE doit être définie (avant d'inclure tout fichier d'en‐tête) afin d'obtenir la définition de cette structure.
Les identifiants que l'émetteur envoie sont vérifiés par le noyau. Un processus avec un UID effectif nul est autorisé à indiquer des valeurs autres que les siennes. L'émetteur doit indiquer son propre PID (sauf s'il a la capacité CAP_SYS_ADMIN), son UID réel, effectif ou sauvé (sauf s'il a la capacité CAP_SETUID), et son GID réel, effectif ou sauvé (sauf s'il a la capacité CAP_SETGID). Pour recevoir un message struct ucred l'option SO_PASSCRED doit être validée sur la socket.
Les ioctl(2)s suivants renvoient des informations dans valeur. La syntaxe correcte est :
int value; error = ioctl(unix_socket, ioctl_type, &value);
ioctl_type peut être :
D'autres erreurs peuvent être déclenchées par le niveau socket générique ou par le système de fichiers. Consultez les pages de manuel correspondantes pour plus de détails.
SCM_CREDENTIALS et l'espace de noms abstrait ont été introduits avec Linux 2.2 et ne doivent pas être utilisés dans des programmes portables. (Certains systèmes dérivés de BSD prennent aussi en charge le passage d'identifiants, mais les détails d'implémentation diffèrent).
Dans l'implémentation Linux, les sockets qui sont visibles dans le système de fichiers honorent les permissions du répertoire où elles se trouvent. Leur propriétaire, groupe et autorisations peuvent être changés. La création d'une nouvelle socket échouera si le processus n'a pas le droit d'écrire et de parcourir (exécution) dans le répertoire où elle est créée. La connexion sur une socket nécessite les permissions de lecture/écriture. Le comportement diffère de plusieurs systèmes dérivés de BSD qui ignorent les permissions sur les sockets de domaine UNIX. Les programmes portables ne doivent pas s'appuyer sur ces fonctionnalités pour la sécurité.
Lier une socket avec un nom de fichier crée la socket dans le système de fichiers, qu'il faudra détruire lorsqu'elle n'est plus utile (en appelant unlink(2)). La sémantique habituelle UNIX s'applique ; la socket peut être effacée à tout moment, et sera effectivement supprimée lorsque sa dernière référence sera fermée.
Pour passer un descripteur ou des identifiants par dessus un SOCK_STREAM, il faut envoyer ou recevoir au moins un octet de donnée non méta dans l'appel sendmsg(2) ou recvmsg(2) correspondant.
Les sockets flux UNIX ne prennent pas en charge la notion de données hors-bande.
Consultez bind(2).
Pour un exemple de l'utilisation de SCM_RIGHTS, consultez cmsg(3).
recvmsg(2), sendmsg(2), socket(2), socketpair(2), cmsg(3), capabilities(7), credentials(7), socket(7)
Cette page fait partie de la publication 3.65 du projet man-pages Linux. Une description du projet et des instructions pour signaler des anomalies peuvent être trouvées à l'adresse http://www.kernel.org/doc/man-pages/.
Depuis 2010, cette traduction est maintenue à l'aide de l'outil po4a <http://po4a.alioth.debian.org/> par l'équipe de traduction francophone au sein du projet perkamon <http://perkamon.alioth.debian.org/>.
Christophe Blaess <http://www.blaess.fr/christophe/> (1996-2003), Alain Portal <http://manpagesfr.free.fr/> (2003-2006). Julien Cristau et l'équipe francophone de traduction de Debian (2006-2009).
Veuillez signaler toute erreur de traduction en écrivant à <debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le paquet manpages-fr.
Vous pouvez toujours avoir accès à la version anglaise de ce document en utilisant la commande « man -L C <section> <page_de_man> ».