Provided by: manpages-fr_2.80.1-1_all bug

NOM

       unix,   PF_UNIX,   AF_UNIX,   PF_LOCAL,   AF_LOCAL   -   Sockets   pour
       communications locales entre processus.

SYNOPSIS

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

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

DESCRIPTION

       La famille de socket PF_UNIX (aussi connue sous le nom PF_LOCAL) sert à
       communiquer  efficacement  entre  processus  sur  la  même machine. Une
       socket Unix peut être  soit  anonyme  (créée  par  socketpair(2))  soit
       associée à un fichier de type socket. Linux supporte aussi 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 supportent la transmission de descripteurs de fichiers
       ou d’identificateurs d’un processus à l’autre en utilisant des  données
       annexes.

   Format dadresse
       Une adresse Unix est définie comme un nom dans le système de fichier ou
       une chaîne unique dans l’espace de noms abstrait.  Les  sockets  créées
       par   socketpair(2)  sont  anonymes.  Pour  les  sockets  non-anonymes,
       l’adresse cible peut être indiquée en utilisant  connect(2).  L’adresse
       locale  peut être fixée avec bind(2). Quand une socket est connectée et
       qu’elle n’a pas  encore  d’adresse  locale,  une  adresse  unique  dans
       l’espace de noms abstrait lui est automatique founie.

           #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. sun_path contient le
       chemin d’accès à la socket, terminé par un zéro,  dans  le  système  de
       fichiers.  Si  sun_path  commence  par  un  octet  nul,  il se réfère à
       l’espace abstrait maintenu par le module du protocole  Unix.  L’adresse
       de  la  socket  dans  cet espace est donné par le reste des octets dans
       sun_path. Notez que  les  noms  dans  l’espace  abstrait  ne  sont  pas
       terminés par un zéro.

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

   Fonctionnalités (non)supportées
       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
       supportées sous Linux.

       Les sockets de domaine Unix ne supportent  pas  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 supporté 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  PF_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 fichiers 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.

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

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

       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 PF_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  supportent  aussi 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 fichier, 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  supportent  pas  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 2.80 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> ».