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'accs : 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> ».