Ubuntu Manpage: unix - Sockets pour communications locales entre processus

NOM

       unix - Sockets pour communications locales entre processus

SYNOPSIS

       #include <sys/socket.h>
       #include <sys/un.h>

       unix_socket = socket(AF_UNIX, type, 0);
       error = socketpair(AF_UNIX, type, 0, int *sv);

DESCRIPTION

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.

Format d'adresse
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 :

* chemin d'accès : une socket de domaine UNIX peut être liée, avec bind(2), à un système
de fichiers dont le chemin d'accès est une chaîne de caractères terminée par l’octet
NULL. Lorsque l'adresse de la socket est obtenue avec getsockname(2), getpeername(2) ou
accept(2), sa longueur vaut

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.

* sans nom : une socket orientée flux qui n'a pu être liée à un chemin d'accès avec
bind(2) n'a pas de nom. De la même façon, les deux sockets crées avec socketpair(2) ne
sont pas nommées. Lorsque l'adresse d'une socket sans nom est obtenue avec
getsockname(2), getpeername(2) ou accept(2), sa longueur vaut sizeof(sa_family_t), et
il n'est pas nécessaire de vérifier sun_path.

* abstraite : une adresse de socket abstraite se reconnaît par le fait que sun_path[0]
est un octet nul (« \0 »). L'adresse de la socket dans cet espace est donnée par le
reste des octets dans sun_path qui sont couverts par la longueur indiquée de la
structure de l'adresse. (Les octets nuls dans le nom n'ont pas de signification
particulière.) Le nom n'a aucun rapport avec les chemins d'accès sur les systèmes de
fichiers. Lorsque l'adresse d'une socket abstraite est obtenue avec getsockname(2),
getpeername(2) ou accept(2), l'addrlen obtenue est plus grande que sizeof(sa_family_t)
(c'est-à-dire plus grande que 2), et le nom de la socket est contenu dans les premiers
bits (addrlen - sizeof(sa_family_t)) de sun_path. L'espace de noms des sockets
abstraites est une extension Linux non portable.

Options de sockets
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.

SO_PASSCRED
Valide la réception des identifiants du processus émetteur dans un message annexe.
Lorsque cette option est active et la socket non encore connectée un nom unique
dans l'espace abstrait sera généré automatiquement. Un attribut booléen entier est
attendu.

Fonctionnalité d'autolien (« autobind »)
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).

API des sockets
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)).

Messages annexes
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).

SCM_RIGHTS
Envoie ou reçoit un jeu de descripteurs de fichier ouverts par un autre processus.
La portion de données contient une table de descripteurs. Les descripteurs passés
se comportent comme s'ils avaient été créés avec dup(2).

SCM_CREDENTIALS
Envoyer ou recevoir les identifiants UNIX. Ça peut servir à l'authentification. Les
identifications sont passés en message annexe en struct ucred. La structure est
définie dans <sys/socket.h> comme ceci :

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.

Ioctls
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 :

SIOCINQ
Renvoie la quantité de données non lues en attente dans le tampon de réception. La
socket ne doit pas être dans l'état LISTEN, sinon l'erreur EINVAL est renvoyée.
SIOCINQ est défini dans <linux/sockios.h>. Une alternative est d'utiliser le
synonyme FIONREAD, défini dans <sys/ioctl.h>.

ERREURS

EADDRINUSE
L'adresse locale indiquée est déjà utilisée ou l'objet existe déjà dans le système
de fichiers.

ECONNREFUSED
L'adresse distante indiquée par connect(2) n'était pas une socket en attente de
connexions. Cette erreur peut également se produire si le nom de fichier cible
n'est pas une socket.

ECONNRESET
La socket distante a été fermée de manière inattendue.

EFAULT Adresse mémoire utilisateur incorrecte.

EINVAL Argument non valable. Une cause habituelle est que la valeur de AF_UNIX n'était pas
indiquée dans le champ sun_type de l'adresse passée, ou que la socket était dans un
état non valable pour l'opération.

EISCONN
connect(2) a été appelée sur une socket déjà connectée, ou l'adresse cible a été
indiquée sur une socket connectée.

ENOENT Le chemin de l'adresse distante indiquée à connect(2) n'existait pas.

ENOMEM Plus de mémoire disponible.

ENOTCONN
L'opération nécessite une adresse cible, mais la socket n'est pas connectée.

EOPNOTSUPP
Opération de flux sur une socket non orientée flux, ou tentative d'utiliser des
options de données hors-bande.

EPERM L'émetteur a transmis des identifiants incorrects dans la struct ucred.

EPIPE La socket distante, de type flux, a été fermée. Dans ce cas un signal SIGPIPE est
émis également. Cela peut être évité en passant l'attribut MSG_NOSIGNAL dans
sendmsg(2) ou recvmsg(2).

EPROTONOSUPPORT
Le protocole passé n'est pas AF_UNIX.

EPROTOTYPE
La socket distante ne correspond pas au type local (SOCK_DGRAM contre SOCK_STREAM)

ESOCKTNOSUPPORT
Type de socket inconnu.

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.

VERSIONS

       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).

NOTES

       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.

EXEMPLE

       Consultez bind(2).

       Pour un exemple de l'utilisation de SCM_RIGHTS, consultez cmsg(3).

VOIR AUSSI

       recvmsg(2),    sendmsg(2),    socket(2),    socketpair(2),    cmsg(3),    capabilities(7),
       credentials(7), socket(7)

COLOPHON

       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/.

TRADUCTION

       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> ».