Provided by: manpages-fr_3.65d1p1-1_all bug

NOM

       unix - 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 valables 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 une 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  système  de  fichiers
          dont le chemin d'accès est une chaîne de caractères terminée par l’octet NULL. 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 noms des sockets abstraites est une extension Linux  non
          portable.

   Options de sockets
       Pour  des  raisons historiques, les options de ces sockets sont indiquées avec un type SOL_SOCKET même si
       elles sont spécifiques AF_UNIX. Elles peuvent être définies avec setsockopt(2) et lues avec getsockopt(2)
       en indiquant 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. Un attribut booléen entier est attendu.

   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ées est donc limité à 2^20 (à partir de Linux 2.1.15,
       quand la fonctionnalité d'autolien a été ajoutée, huit octets étaient utilisés, et le  nombre  d'adresses
       autoliées était donc limité à 2^32. La modification à cinq octets est intervenue avec Linux 2.3.15).

   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 indiqués avec un type SOL_SOCKET même s'ils sont
       spécifiques  AF_UNIX.  Pour  les  envoyer,  définissez  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.  Ça  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 value;
              error = ioctl(unix_socket, ioctl_type, &value);

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

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

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

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

       Pour un exemple de l'utilisation de SCM_RIGHTS, consultez cmsg(3).

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

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

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

Linux                                              10 mai 2012                                           UNIX(7)