UNIX
Section : Manuel de l'administrateur Linux (
7)
Mise à jour de la version anglaise : 17 juin 2008
Index
Menu principal
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.
Index
- NOM
-
- SYNOPSIS
-
- DESCRIPTION
-
- Format d'adresse
-
- Options de sockets
-
- Fonctionnalités (non) prises en charge
-
- Messages annexes
-
- ERREURS
-
- VERSIONS
-
- NOTES
-
- EXEMPLE
-
- VOIR AUSSI
-
- TRADUCTION
-
Dernière mise à jour : 17 juillet 2008