Provided by: manpages-fr_3.32d0.2p4-1_all bug

NOM

       unix, AF_UNIX, AF_LOCAL - 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  valides  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  un 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 fichier
          dont le chemin d'accès est une chaîne de caractères terminée par un octet nul.  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  nom  des  sockets
          abstraites est une extension Linux non portable.

   Options de sockets
       Pour  des  raisons  historiques,  les  options de ces sockets sont spécifiées avec un type
       SOL_SOCKET même si elles sont spécifiques AF_UNIX. On peut les fixer avec setsockopt(2) et
       les lire avec getsockopt(2) en spécifiant 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. On attend un attribut booléen
              entier.

   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és est donc limité à 2^20).

   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 spécifiés avec un
       type SOL_SOCKET même s'ils sont spécifiques AF_UNIX. Pour  les  envoyer,  fixez  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. Ceci 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 valeur;
              error = ioctl(tcp_socket, ioctl_type, &valeur);

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

       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() 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 invalide dans la struct ucred.

       EPIPE  La socket distante, de type flux, a été fermée. Dans ce cas un signal  SIGPIPE  est
              émis  également.  Ceci  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 inconu.

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

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.32 du projet man-pages Linux. Une description
       du projet et des  instructions  pour  signaler  des  anomalies  peuvent  être  trouvées  à
       l'adresse <URL:http://www.kernel.org/doc/man-pages/>.

TRADUCTION

       Depuis    2010,    cette   traduction   est   maintenue   à   l'aide   de   l'outil   po4a
       <URL:http://po4a.alioth.debian.org/> par l'équipe de traduction  francophone  au  sein  du
       projet perkamon <URL:http://perkamon.alioth.debian.org/>.

       Christophe   Blaess   <URL:http://www.blaess.fr/christophe/>   (1996-2003),  Alain  Portal
       <URL: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> ».