Editer un article - Informaticien.be

Editer un article

Titre
Mots Clés
Texte	[size=18] [b]Nom[/b] [/size] unix, PF_UNIX, AF_UNIX, PF_LOCAL, AF_LOCAL - Sockets pour communications locales entre processus. [size=18] [b]Résumé[/b] [/size] [b]#include <sys/socket.h>[/b] [b][/b] [b]#include <sys/un.h>[/b] [b][i]unix_socket = socket(PF_UNIX, type, 0);[/i][/b] [b][/b] [b][i]error = socketpair(PF_UNIX, type, 0, int * sv );[/i][/b] [size=18] [b]Description[/b] [/size] La famille de socket [b]PF_UNIX[/b] (aussi connue sous le nom [b]PF_LOCAL )[/b] sert à communiquer efficacement entre processus sur la même machine. Une socket Unix peut être soit anonyme (créée par [b]socketpair (2))[/b] 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 [b]SOCK_STREAM [/b] pour une socket orientée flux, et [b]SOCK_DGRAM[/b] 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. [size=18] [b]Format dadresse[/b] [/size] 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 [b]socketpair (2)[/b] sont anonymes. Pour les sockets non-anonymes, l'adresse cible peut être indiquée en utilisant [b]connect (2). [/b] L'adresse locale peut être fixée avec [b]bind (2). [/b] 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. [table][row][col]    [/col][col] .nf #define UNIX_PATH_MAX 108 .ta 4n 17n 42n struct sockaddr_un { sa_family_t sun_family; /* AF_UNIX / char sun_path[UNIX_PATH_MAX]; / chemin accès / }; .fi[/col][/row][/table] [b]sun_family [/b] contient toujours la valeur [b]AF_UNIX .[/b] [b]sun_path[/b] contient le chemin d'accès à la socket, terminé par un zéro, dans le système de fichiers. Si [b]sun_path[/b] 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 [b]sun_path .[/b] Notez que les noms dans l'espace abstrait ne sont pas terminés par un zéro. [size=18] [b]Options[/b] [/size] 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 [b]setsockopt (2)[/b] et les lire avec [b]getsockopt (2)[/b] en spécifiant la famille SOL_SOCKET. [b]SO_PASSCRED[/b] [table][row][col]    [/col][col]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. [/col][/row][/table] [size=18] [b]Messages annexes[/b] [/size] Les données annexes sont envoyées et reçues en utilisant [b]sendmsg (2)[/b] et [b]recvmsg (2).[/b] 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 sépcifiques PF_UNIX. Pour les envoyer, fixez le champ [b]cmsg_level[/b] de la structure [b]cmsghdr[/b] à SOL_SOCKET et le champ [b]cmsg_type [/b] avec le type du message. Pour plus de détails, voir [b]cmsg (3). [/b] [b]SCM_RIGHTS[/b] [table][row][col]    [/col][col]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 [b]dup (2).[/b] [/col][/row][/table] [b]SCM_CREDENTIALS[/b] [table][row][col]    [/col][col]Envoyer ou recevoir les identifiants Unix. Ceci peut servir à l'authentification. Les identifications sont passés en message annexe en [b]struct ucred .[/b] [table][row][col]    [/col][col] .nf .ta 4n 11n 17n struct ucred { pid_t pid; / PID processus émetteur / uid_t uid; / UID processus émetteur / gid_t gid; / GID processus émetteur */ }; .fi[/col][/row][/table] 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é [b]CAP_SYS_ADMIN ),[/b] son UID réel, effectif ou sauvé (sauf s'il a la capacité [b]CAP_SETUID ),[/b] et son GID réel, effecif ou sauvé (sauf s'il a la capacité [b]CAP_SETGID ).[/b] Pour recevoir un message [b]struct ucred[/b] l'option [b]SO_PASSCRED [/b] doit être validée sur la socket. [/col][/row][/table] [size=18] [b]Versions[/b] [/size] [b]SCM_CREDENTIALS[/b] 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). [size=18] [b]Notes[/b] [/size] 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ées. La création d'une nouvelle socket échouera si le processus n'a pas le droit d'écrire et de parcours (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 portable ne doivent pas s'appuyer sur ces fonctionnalités pour la sécurité. Lier une socket avec un nom de fichier créer la socket dans le système de fichier, qu'il faudra détruire lorsqu'elle n'est plus utile (en appelant [b]unlink (2)).[/b] 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, il faut envoyer ou recevoir au moins un octet de donnée. Les sockets flux Unix ne supportent pas la notion de données hors-bande. [size=18] [b]Erreurs[/b] [/size] [b]ENOMEM[/b] [table][row][col]    [/col][col]Plus de mémoire.[/col][/row][/table] [b]ECONNREFUSED[/b] [b]connect (2)[/b] [table][row][col]    [/col][col]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.[/col][/row][/table] [b]EINVAL[/b] [table][row][col]    [/col][col]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.[/col][/row][/table] [b]EOPNOTSUPP[/b] [table][row][col]    [/col][col]Opération de flux sur une socket non orientée flux, ou tentatice d'utiliser des options de données hors-bande.[/col][/row][/table] [b]EPROTONOSUPPORT[/b] [table][row][col]    [/col][col]Le protocole passé n'est pas PF_UNIX.[/col][/row][/table] [b]ESOCKTNOSUPPORT[/b] [table][row][col]    [/col][col]Type de socket inconu.[/col][/row][/table] [b]EPROTOTYPE[/b] [table][row][col]    [/col][col]La socket distante ne correspond pas au type local (SOCK_DGRAM vs. SOCK_STREAM)[/col][/row][/table] [b]EADDRINUSE[/b] [table][row][col]    [/col][col]L'adresse locale est déjà prise ou l'objet existe déjà dans le système de fichier.[/col][/row][/table] [b]EISCONN[/b] [b]connect (2)[/b] [table][row][col]    [/col][col]a été appelée sur une socket déjà connectée, ou l'adresse cible a été indiquée sur une socket connectée.[/col][/row][/table] [b]ENOTCONN[/b] [table][row][col]    [/col][col]L'opération nécessite une adresse cible, mais la socket n'est pas connectée.[/col][/row][/table] [b]ECONNRESET[/b] [table][row][col]    [/col][col]La socket distante a été fermée de manière inattendue.[/col][/row][/table] [b]EPIPE[/b] [table][row][col]    [/col][col]La socket distante, de type flux, a été fermée. Dans ce cas un signal [b]SIGPIPE [/b] est émis également. Ceci peut être évité en passant l'attribut [b]MSG_NOSIGNAL[/b] dans [b]sendmsg (2)[/b] ou [b]recvmsg (2).[/b][/col][/row][/table] [b]EFAULT[/b] [table][row][col]    [/col][col]Adresse mémoire utilisateur invalide.[/col][/row][/table] [b]EPERM[/b] [table][row][col]    [/col][col]L'émetteur a transmis des identifiants invalide dans la [b]struct ucred .[/b][/col][/row][/table] 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. [size=18] [b]Voir aussi[/b] [/size] [b]recvmsg (2),[/b] [b]sendmsg (2),[/b] [b]socket (2),[/b] [b]socketpair (2),[/b] [b]cmsg (3),[/b] [b]capabilities (7),[/b] [b]socket (7)[/b] [size=18] [b]Auteur[/b] [/size] Cette page de manuel a été écrite par Andi Kleen. [size=18] [b]Traduction[/b] [/size] Christophe Blaess, 2003.
Fichier