Provided by:
manpages-fr_3.32d0.2p4-1_all 
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);
DESCRIPTION
La famille de socket AF_UNIX (aussi connue sous le nom AF_LOCAL) sert a
communiquer efficacement entre processus sur la meme machine.
Traditionnellement, les sockets de domaine UNIX peuvent ne pas etre
nommees ou bien etre liees a un chemin d'acces, lequel sera marque
comme etant de type socket, sur un systeme de fichiers. Linux gere
egalement un espace de noms abstrait, independant du systeme de
fichiers.
Les types valides sont : SOCK_STREAM, pour une socket orientee flux et
SOCK_DGRAM, pour une socket orientee datagramme, preservant les limites
entre messages (comme sur la plupart des implementations UNIX, les
sockets datagramme de domaine UNIX sont toujours fiables et ne
reordonnent pas les datagrammes) ; et (depuis Linux 2.6.4)
SOCK_SEQPACKET, pour un socket orientee connexion, preservant les
limites entre messages et delivrant les messages dans l'ordre ou ils
ont ete envoyes.
Les sockets de domaine UNIX prennent en charge la transmission de
descripteurs de fichier ou d'identificateurs d'un processus a l'autre
en utilisant des donnees annexes.
Format d'adresse
Une adresse de socket de domaine UNIX est representee 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 acces */
};
sun_family contient toujours la valeur AF_UNIX.
On considere trois types d'adresse pour cette structure :
* chemin d'acc`es : une socket de domaine UNIX peut etre liee, avec
bind(2), a un fichier dont le chemin d'acces est une chaine de
caracteres terminee par un octet nul. 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 chaine de caracteres,
terminee par un octet nul, representant le chemin d'acces.
* sans nom : une socket orientee flux qui n'a pu etre liee a un chemin
d'acces avec bind(2) n'a pas de nom. De la meme facon, les deux
sockets crees avec socketpair(2) ne sont pas nommees. 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 necessaire de verifier sun_path.
* abstraite : une adresse de socket abstraite se reconnait par le fait
que sun_path[0] est un octet nul (<< \0 >>). L'adresse de la socket
dans cet espace est donnee par le reste des octets dans sun_path qui
sont couverts par la longueur indiquee de la structure de l'adresse.
(Les octets nuls dans le nom n'ont pas de signification
particuliere.) Le nom n'a aucun rapport avec les chemins d'acces sur
les systemes 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-a-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 nom des sockets abstraites est une extension Linux non
portable.
Options de sockets
Pour des raisons historiques, les options de ces sockets sont
specifiees avec un type SOL_SOCKET meme si elles sont specifiques
AF_UNIX. On peut les fixer avec setsockopt(2) et les lire avec
getsockopt(2) en specifiant la famille SOL_SOCKET.
SO_PASSCRED
Valide la reception des identifiants du processus emetteur dans
un message annexe. Lorsque cette option est active et la socket
non encore connectee un nom unique dans l'espace abstrait sera
genere automatiquement. On attend un attribut booleen entier.
Fonctionnalit'e d'autolien (<< autobind >>)
Si un appel bind(2) indique addrlen comme sizeof(sa_family_t), ou si
l'option de socket SO_PASSCRED etait indiquee pour une socket qui
n'etait pas liee explicitement a une adresse, alors la socket est
autoliee a une adresse abstraite. L'adresse est constitue d'un octet
nul suivi par cinq octets de l'ensemble de caracteres [0-9a-f] (le
nombre d'adresses autolies est donc limite a 2^20).
API des sockets
Les paragraphes suivants decrivent des details specifiques au domaine
UNIX, et des fonctionnalites 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
donnees 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 parametre 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 superieure a la taille des datagrammes sortants.
Cette limite est calculee comme le double de la valeur de l'option,
moins 32 octets utilises par le systeme (consultez socket(7)).
Messages annexes
Les donnees annexes sont envoyees et recues en utilisant sendmsg(2) et
recvmsg(2). Pour des raisons historiques, les messages annexes listes
ci-dessous sont specifies avec un type SOL_SOCKET meme s'ils sont
specifiques AF_UNIX. Pour les envoyer, fixez le champ cmsg_level de la
structure cmsghdr a SOL_SOCKET et le champ cmsg_type avec le type du
message. Pour plus de details, consultez cmsg(3).
SCM_RIGHTS
Envoie ou recoit un jeu de descripteurs de fichier ouverts par
un autre processus. La portion de donnees contient une table de
descripteurs. Les descripteurs passes se comportent comme s'ils
avaient ete crees avec dup(2).
SCM_CREDENTIALS
Envoyer ou recevoir les identifiants UNIX. Ceci peut servir a
l'authentification. Les identifications sont passes en message
annexe en struct ucred. La structure est definie dans
<sys/socket.h> comme ceci :
struct ucred {
pid_t pid; /* PID processus emetteur */
uid_t uid; /* UID processus emetteur */
gid_t gid; /* GID processus emetteur */
};
Depuis la glibc 2.8, la macro de test de fonctionnalites
_GNU_SOURCE doit etre definie (avant d'inclure tout fichier
d'en-tete) afin d'obtenir la definition de cette structure.
Les identifiants que l'emetteur envoie sont verifies par le
noyau. Un processus avec un UID effectif nul est autorise a
indiquer des valeurs autres que les siennes. L'emetteur doit
indiquer son propre PID (sauf s'il a la capacite CAP_SYS_ADMIN),
son UID reel, effectif ou sauve (sauf s'il a la capacite
CAP_SETUID), et son GID reel, effectif ou sauve (sauf s'il a la
capacite CAP_SETGID). Pour recevoir un message struct ucred
l'option SO_PASSCRED doit etre validee sur la socket.
Ioctls
Les ioctl(2)s suivants renvoient des informations dans valeur. La
syntaxe correcte est :
int valeur;
error = ioctl(tcp_socket, ioctl_type, &valeur);
ioctl_type peut etre :
SIOCINQ
Renvoie la quantite de donnees non lues en attente dans le
tampon de reception. La socket ne doit pas etre dans l'etat
LISTEN, sinon l'erreur EINVAL est renvoyee. SIOCINQ est defini
dans <linux/sockios.h>. Une alternative est d'utiliser le
synonyme FIONREAD, defini dans <sys/ioctl.h>.
ERREURS
EADDRINUSE
L'adresse locale indiquee est deja utilisee ou l'objet existe
deja dans le systeme de fichiers.
ECONNREFUSED
L'adresse distante indiquee par connect(2) n'etait pas une
socket en attente de connexions. Cette erreur peut egalement se
produire si le nom de fichier cible n'est pas une socket.
ECONNRESET
La socket distante a ete fermee de maniere inattendue.
EFAULT Adresse memoire utilisateur invalide.
EINVAL Argument non valable. Une cause habituelle est que la valeur de
AF_UNIX n'etait pas indiquee dans le champ sun_type de l'adresse
passee, ou que la socket etait dans un etat non valable pour
l'operation.
EISCONN
connect(2) a ete appelee sur une socket deja connectee, ou
l'adresse cible a ete indiquee sur une socket connectee.
ENOENT Le chemin de l'adresse distante indiquee a connect() n'existait
pas.
ENOMEM Plus de memoire disponible.
ENOTCONN
L'operation necessite une adresse cible, mais la socket n'est
pas connectee.
EOPNOTSUPP
Operation de flux sur une socket non orientee flux, ou tentative
d'utiliser des options de donnees hors-bande.
EPERM L'emetteur a transmis des identifiants invalide dans la struct
ucred.
EPIPE La socket distante, de type flux, a ete fermee. Dans ce cas un
signal SIGPIPE est emis egalement. Ceci peut etre evite en
passant l'attribut MSG_NOSIGNAL dans sendmsg(2) ou recvmsg(2).
EPROTONOSUPPORT
Le protocole passe n'est pas AF_UNIX.
EPROTOTYPE
La socket distante ne correspond pas au type local (SOCK_DGRAM
contre SOCK_STREAM)
ESOCKTNOSUPPORT
Type de socket inconu.
D'autres erreurs peuvent etre declenchees par le niveau socket
generique ou par le systeme de fichiers. Consultez les pages de manuel
correspondantes pour plus de details.
VERSIONS
SCM_CREDENTIALS et l'espace de noms abstrait ont ete introduits avec
Linux 2.2 et ne doivent pas etre utilises dans des programmes
portables. (Certains systemes derives de BSD prennent aussi en charge
le passage d'identifiants, mais les details d'implementation
different).
NOTES
Dans l'implementation Linux, les sockets qui sont visibles dans le
systeme de fichiers honorent les permissions du repertoire ou elles se
trouvent. Leur proprietaire, groupe et autorisations peuvent etre
changes. La creation d'une nouvelle socket echouera si le processus n'a
pas le droit d'ecrire et de parcourir (execution) dans le repertoire ou
elle est creee. La connexion sur une socket necessite les permissions
de lecture/ecriture. Le comportement differe de plusieurs systemes
derives de BSD qui ignorent les permissions sur les sockets de domaine
UNIX. Les programmes portables ne doivent pas s'appuyer sur ces
fonctionnalites pour la securite.
Lier une socket avec un nom de fichier cree la socket dans le systeme
de fichiers, qu'il faudra detruire lorsqu'elle n'est plus utile (en
appelant unlink(2)). La semantique habituelle UNIX s'applique ; la
socket peut etre effacee a tout moment, et sera effectivement supprimee
lorsque sa derniere reference sera fermee.
Pour passer un descripteur ou des identifiants par dessus un
SOCK_STREAM, il faut envoyer ou recevoir au moins un octet de donnee
non-meta dans l'appel sendmsg(2) ou recvmsg(2) correspondant.
Les sockets flux UNIX ne prennent pas en charge la notion de donnees
hors-bande.
EXEMPLE
Consultez 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.32 du projet man-pages
Linux. Une description du projet et des instructions pour signaler des
anomalies peuvent etre trouvees a l'adresse
<URL:http://www.kernel.org/doc/man-pages/>.
TRADUCTION
Depuis 2010, cette traduction est maintenue a l'aide de l'outil po4a
<URL:http://po4a.alioth.debian.org/> par l'equipe de traduction
francophone au sein du projet perkamon
<URL:http://perkamon.alioth.debian.org/>.
Christophe Blaess <URL:http://www.blaess.fr/christophe/> (1996-2003),
Alain Portal <URL:http://manpagesfr.free.fr/> (2003-2006). Julien
Cristau et l'equipe francophone de traduction de Debian (2006-2009).
Veuillez signaler toute erreur de traduction en ecrivant a
<debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le
paquet manpages-fr.
Vous pouvez toujours avoir acces a la version anglaise de ce document
en utilisant la commande << man -L C <section> <page_de_man> >>.