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 a
       communiquer   efficacement   entre   processus  sur  la  meme  machine.
       Traditionnellement, les sockets de domaine UNIX  peuvent  ne  pas  etre
       nommees  ou  bien  etre  liees  a un chemin d'acces, lequel sera marque
       comme etant de type socket, sur un  systeme  de  fichiers.  Linux  gere
       egalement  un  espace  de  noms  abstrait,  independant  du  systeme de
       fichiers.

       Les types valides sont : SOCK_STREAM, pour une socket orientee flux  et
       SOCK_DGRAM, pour une socket orientee datagramme, preservant les limites
       entre messages (comme sur la  plupart  des  implementations  UNIX,  les
       sockets  datagramme  de  domaine  UNIX  sont  toujours  fiables  et  ne
       reordonnent   pas   les   datagrammes) ;   et   (depuis    Linux 2.6.4)
       SOCK_SEQPACKET,  pour  un  socket  orientee  connexion,  preservant les
       limites entre messages et delivrant les messages dans  l'ordre  ou  ils
       ont ete envoyes.

       Les  sockets  de  domaine  UNIX  prennent  en charge la transmission de
       descripteurs de fichier ou d'identificateurs d'un processus  a  l'autre
       en utilisant des donnees annexes.

   Format d'adresse
       Une adresse de socket de domaine UNIX est representee 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 acces */
           };

       sun_family contient toujours la valeur AF_UNIX.

       On considere trois types d'adresse pour cette structure :

       *  chemin d'acc`es : une socket de domaine UNIX  peut  etre  liee,  avec
          bind(2),  a  un  fichier  dont  le  chemin d'acces est une chaine de
          caracteres terminee 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 chaine de caracteres,
          terminee par un octet nul, representant le chemin d'acces.

       *  sans nom : une socket orientee flux qui n'a pu etre liee a un chemin
          d'acces  avec  bind(2)  n'a  pas  de nom. De la meme facon, les deux
          sockets crees  avec  socketpair(2)  ne  sont  pas  nommees.  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 necessaire de verifier sun_path.

       *  abstraite : une adresse de socket abstraite se reconnait par le fait
          que sun_path[0] est un octet nul (<< \0 >>). L'adresse de la  socket
          dans cet espace est donnee par le reste des octets dans sun_path qui
          sont couverts par la longueur indiquee de la structure de l'adresse.
          (Les   octets   nuls   dans   le  nom  n'ont  pas  de  signification
          particuliere.) Le nom n'a aucun rapport avec les chemins d'acces sur
          les  systemes  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-a-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
       specifiees avec un type  SOL_SOCKET  meme  si  elles  sont  specifiques
       AF_UNIX.  On  peut  les  fixer  avec  setsockopt(2)  et  les  lire avec
       getsockopt(2) en specifiant la famille SOL_SOCKET.

       SO_PASSCRED
              Valide la reception des identifiants du processus emetteur  dans
              un  message annexe. Lorsque cette option est active et la socket
              non encore connectee un nom unique dans l'espace  abstrait  sera
              genere automatiquement. On attend un attribut booleen entier.

   Fonctionnalit'e d'autolien (<< autobind >>)
       Si  un  appel  bind(2) indique addrlen comme sizeof(sa_family_t), ou si
       l'option de socket SO_PASSCRED  etait  indiquee  pour  une  socket  qui
       n'etait  pas  liee  explicitement  a  une  adresse, alors la socket est
       autoliee a une adresse abstraite. L'adresse est  constitue  d'un  octet
       nul  suivi  par  cinq  octets  de l'ensemble de caracteres [0-9a-f] (le
       nombre d'adresses autolies est donc limite a 2^20).

   API des sockets
       Les paragraphes suivants decrivent des details specifiques  au  domaine
       UNIX,  et  des fonctionnalites 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
       donnees 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 parametre 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  superieure  a  la taille des datagrammes sortants.
       Cette limite est calculee comme le double de  la  valeur  de  l'option,
       moins 32 octets utilises par le systeme (consultez socket(7)).

   Messages annexes
       Les  donnees annexes sont envoyees et recues en utilisant sendmsg(2) et
       recvmsg(2). Pour des raisons historiques, les messages  annexes  listes
       ci-dessous  sont  specifies  avec  un  type  SOL_SOCKET meme s'ils sont
       specifiques AF_UNIX. Pour les envoyer, fixez le champ cmsg_level de  la
       structure  cmsghdr  a  SOL_SOCKET et le champ cmsg_type avec le type du
       message. Pour plus de details, consultez cmsg(3).

       SCM_RIGHTS
              Envoie ou recoit un jeu de descripteurs de fichier  ouverts  par
              un  autre processus. La portion de donnees contient une table de
              descripteurs. Les descripteurs passes se comportent comme  s'ils
              avaient ete crees avec dup(2).

       SCM_CREDENTIALS
              Envoyer  ou  recevoir  les identifiants UNIX. Ceci peut servir a
              l'authentification. Les identifications sont passes  en  message
              annexe   en   struct   ucred.  La  structure  est  definie  dans
              <sys/socket.h> comme ceci :

                  struct ucred {
                      pid_t pid;    /* PID processus emetteur */
                      uid_t uid;    /* UID processus emetteur */
                      gid_t gid;    /* GID processus emetteur */
                  };

              Depuis  la  glibc 2.8,  la  macro  de  test  de  fonctionnalites
              _GNU_SOURCE  doit  etre  definie  (avant  d'inclure tout fichier
              d'en-tete) afin d'obtenir la definition de cette structure.

              Les identifiants que l'emetteur  envoie  sont  verifies  par  le
              noyau.  Un  processus  avec  un  UID effectif nul est autorise a
              indiquer des valeurs autres que  les  siennes.  L'emetteur  doit
              indiquer son propre PID (sauf s'il a la capacite CAP_SYS_ADMIN),
              son UID reel,  effectif  ou  sauve  (sauf  s'il  a  la  capacite
              CAP_SETUID),  et son GID reel, effectif ou sauve (sauf s'il a la
              capacite CAP_SETGID). Pour  recevoir  un  message  struct  ucred
              l'option SO_PASSCRED doit etre validee 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 etre :

       SIOCINQ
              Renvoie la quantite de donnees  non  lues  en  attente  dans  le
              tampon  de  reception.  La  socket  ne doit pas etre dans l'etat
              LISTEN, sinon l'erreur EINVAL est renvoyee. SIOCINQ  est  defini
              dans   <linux/sockios.h>.  Une  alternative  est  d'utiliser  le
              synonyme FIONREAD, defini dans <sys/ioctl.h>.

ERREURS

       EADDRINUSE
              L'adresse locale indiquee est deja utilisee  ou  l'objet  existe
              deja dans le systeme de fichiers.

       ECONNREFUSED
              L'adresse  distante  indiquee  par  connect(2)  n'etait  pas une
              socket en attente de connexions. Cette erreur peut egalement  se
              produire si le nom de fichier cible n'est pas une socket.

       ECONNRESET
              La socket distante a ete fermee de maniere inattendue.

       EFAULT Adresse memoire utilisateur invalide.

       EINVAL Argument  non valable. Une cause habituelle est que la valeur de
              AF_UNIX n'etait pas indiquee dans le champ sun_type de l'adresse
              passee,  ou  que  la  socket etait dans un etat non valable pour
              l'operation.

       EISCONN
              connect(2) a ete appelee  sur  une  socket  deja  connectee,  ou
              l'adresse cible a ete indiquee sur une socket connectee.

       ENOENT Le  chemin de l'adresse distante indiquee a connect() n'existait
              pas.

       ENOMEM Plus de memoire disponible.

       ENOTCONN
              L'operation necessite une adresse cible, mais  la  socket  n'est
              pas connectee.

       EOPNOTSUPP
              Operation de flux sur une socket non orientee flux, ou tentative
              d'utiliser des options de donnees hors-bande.

       EPERM  L'emetteur a transmis des identifiants invalide dans  la  struct
              ucred.

       EPIPE  La  socket  distante, de type flux, a ete fermee. Dans ce cas un
              signal SIGPIPE est emis  egalement.  Ceci  peut  etre  evite  en
              passant l'attribut MSG_NOSIGNAL dans sendmsg(2) ou recvmsg(2).

       EPROTONOSUPPORT
              Le protocole passe 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  etre  declenchees  par  le  niveau   socket
       generique  ou par le systeme de fichiers. Consultez les pages de manuel
       correspondantes pour plus de details.

VERSIONS

       SCM_CREDENTIALS et l'espace de noms abstrait ont  ete  introduits  avec
       Linux 2.2   et  ne  doivent  pas  etre  utilises  dans  des  programmes
       portables. (Certains systemes derives de BSD prennent aussi  en  charge
       le   passage   d'identifiants,   mais   les   details  d'implementation
       different).

NOTES

       Dans l'implementation Linux, les sockets  qui  sont  visibles  dans  le
       systeme  de fichiers honorent les permissions du repertoire ou elles se
       trouvent. Leur  proprietaire,  groupe  et  autorisations  peuvent  etre
       changes. La creation d'une nouvelle socket echouera si le processus n'a
       pas le droit d'ecrire et de parcourir (execution) dans le repertoire ou
       elle  est  creee. La connexion sur une socket necessite les permissions
       de lecture/ecriture. Le  comportement  differe  de  plusieurs  systemes
       derives  de BSD qui ignorent les permissions sur les sockets de domaine
       UNIX. Les  programmes  portables  ne  doivent  pas  s'appuyer  sur  ces
       fonctionnalites pour la securite.

       Lier  une  socket avec un nom de fichier cree la socket dans le systeme
       de fichiers, qu'il faudra detruire lorsqu'elle  n'est  plus  utile  (en
       appelant  unlink(2)).  La  semantique  habituelle  UNIX s'applique ; la
       socket peut etre effacee a tout moment, et sera effectivement supprimee
       lorsque sa derniere reference sera fermee.

       Pour   passer   un  descripteur  ou  des  identifiants  par  dessus  un
       SOCK_STREAM, il faut envoyer ou recevoir au moins un  octet  de  donnee
       non-meta dans l'appel sendmsg(2) ou recvmsg(2) correspondant.

       Les  sockets  flux  UNIX ne prennent pas en charge la notion de donnees
       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       etre       trouvees      a      l'adresse
       <URL:http://www.kernel.org/doc/man-pages/>.

TRADUCTION

       Depuis 2010, cette traduction est maintenue a l'aide  de  l'outil  po4a
       <URL:http://po4a.alioth.debian.org/>   par   l'equipe   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'equipe francophone de traduction de Debian (2006-2009).

       Veuillez   signaler   toute   erreur   de   traduction  en  ecrivant  a
       <debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le
       paquet manpages-fr.

       Vous  pouvez  toujours avoir acces a la version anglaise de ce document
       en utilisant la commande << man -L C <section> <page_de_man> >>.