Provided by: manpages-fr_1.67.0-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.   Les  socket  Unix  sont  toujours  fiables   et   ne
       réordonnent pas les datagrammes.

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

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, effecif 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.

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

       Les sockets flux Unix ne supportent pas  la  notion  de  données  hors-
       bande.

ERREURS

       ENOMEM Plus de mémoire.

       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.

       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.

       EOPNOTSUPP
              Opération de flux sur une socket non orientée flux, ou tentatice
              d’utiliser des options de données hors-bande.

       EPROTONOSUPPORT
              Le protocole passé n’est pas PF_UNIX.

       ESOCKTNOSUPPORT
              Type de socket inconu.

       EPROTOTYPE
              La socket distante ne correspond pas au type  local  (SOCK_DGRAM
              vs.  SOCK_STREAM)

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

       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.

       ENOTCONN
              L’opération  nécessite  une  adresse cible, mais la socket n’est
              pas connectée.

       ECONNRESET
              La socket distante a été fermée de manière inattendue.

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

       EFAULT Adresse mémoire utilisateur invalide.

       EPERM  L’émetteur a transmis des identifiants invalide dans  la  struct
              ucred.

       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.

VOIR AUSSI

       recvmsg(2),     sendmsg(2),    socket(2),    socketpair(2),    cmsg(3),
       capabilities(7), socket(7)

AUTEUR

       Andi Kleen.

TRADUCTION

       Ce document est une traduction réalisée par Christophe Blaess  <ccb  AT
       club-internet  DOT  fr>  le 25 juillet 2003 et révisée par Alain Portal
       <aportal AT univ-montp2 DOT fr> le 23 décembre 2005.

       L’équipe de traduction a fait le maximum pour réaliser  une  adaptation
       française de qualité. La version anglaise la plus à jour de ce document
       est toujours  consultable  via  la  commande :  « LANG=en man 7 unix ».
       N’hésitez  pas  à  signaler  à l’auteur ou au traducteur, selon le cas,
       toute erreur dans cette page de manuel.