NOM
unix, AF_UNIX, AF_LOCAL - 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);
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 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 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 daccs : 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
AF_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.
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 (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 AF_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. 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 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.
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 AF_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 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 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
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 3.23 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> ».