Provided by: manpages-fr_3.23.1-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 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 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 dadresse
       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  daccs :  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  sizeof(sa_family_t)  +  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 reconnait par le fait
          que sun_path[0] est un octet nul (« \0 »). Tous les autres octets de
          sun_path définissent le « nom » de la socket. (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.
          L’adresse  de  la socket dans cet espace est donnée par le reste des
          octets dans sun_path. Lorsque l’adresse d’une socket  abstraite  est
          obtenue   avec   getsockname(2),  getpeername(2)  ou  accept(2),  sa
          longueur vaut sizeof(struct sockaddr_un), et  sun_path  contient  le
          nom  abstrait.  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 dans les messages annexes
              du processus émetteur. 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.

   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 (voir 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, voir 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 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.

ERREURS

       EADDRINUSE
              L’adresse locale est déjà prise ou l’objet existe déjà  dans  le
              système de fichiers.

       ECONNREFUSED
              connect(2)  a été appelé sur une socket qui n’est pas en écoute.
              Ceci peut arriver si la socket distante n’existe pas  ou  si  le
              fichier 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  invalide.  Une cause habituelle est l’oubli de AF_UNIX
              dans le champ sun_type de l’adresse passée ou lorsque la  socket
              est dans un état invalide 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.

       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
              vs. 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. Voir 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 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

       Voir 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.23 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

       Cette page de manuel a été traduite  et  mise  à  jour  par  Christophe
       Blaess  <http://www.blaess.fr/christophe/> entre 1996 et 2003, puis par
       Alain Portal <aportal AT univ-montp2 DOT fr> jusqu’en 2006, et  mise  à
       disposition sur http://manpagesfr.free.fr/.

       Les mises à jour et corrections de la version présente dans Debian sont
       directement gérées par Julien Cristau <jcristau@debian.org> et l’équipe
       francophone de traduction de Debian.

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