Provided by:
manpages-fr_1.67.0-1_all 
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 Dâ€â€™ADRESSE
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.