UNIX(7)

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. 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 supportent 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 d'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 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 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) prises en charge
Le paragraphe suivant décrit les détails spécifiques au domaine Unix et les fonctionnalités de l'API des sockets de domaine Unix non prises en charge sous Linux. Les sockets de domaine Unix ne supportent pas la transmission 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 l'option 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 étant le double (voir socket(7)) de la valeur de l'option moins 32 octets utilisés par le système.

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

TRADUCTION

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

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=C man 7 unix ». N'hésitez pas à signaler à l'auteur ou au traducteur, selon le cas, toute erreur dans cette page de manuel.