unix

UNIX(7)                   Manuel du programmeur Linux                  UNIX(7)



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.70 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 Ã
       <perkamon-fr@traduc.org>.

       Vous pouvez toujours avoir accès à la version anglaise de ce document
       en utilisant la commande « LC_ALL=C man <section> <page_de_man> ».



Linux                             10 mai 2012                          UNIX(7)