Man page 7 : unix

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 :

* 3 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 offsetof(struct sockaddr_un, sun_path) + 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 reconnaît par le fait que sun_path[0] est un octet nul (« \0 »). L'adresse de la socket dans cet espace est donnée par le reste des octets dans sun_path qui sont couverts par la longueur indiquée de la structure de l'adresse. (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. 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-à-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 noms des sockets abstraites est une extension Linux non portable.

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 définir avec setsockopt(2) et les lire avec getsockopt(2) en spécifiant la famille SOL_SOCKET.

• SO_PASSCRED
      Valide la réception des identifiants du processus émetteur dans un message annexe. 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.

Si un appel bind(2) indique addrlen comme sizeof(sa_family_t), ou si l'option de socket SO_PASSCRED était indiquée pour une socket qui n'était pas liée explicitement à une adresse, alors la socket est autoliée à une adresse abstraite. L'adresse est constitué d'un octet nul suivi par cinq octets de l'ensemble de caractères [0-9a-f]. Le nombre d'adresses autoliées est donc limité à 2^20 (à partir de Linux 2.1.15, quand la fonctionnalité d'autolien a été ajoutée, huit octets étaient utilisés, et le nombre d'adresses autoliées était donc limité à 2^32. La modification à cinq octets est intervenue avec Linux 2.3.15).

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 (consultez socket(7)).

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, définissez 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, consultez 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 (avant d'inclure tout fichier d'en(hytête) 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.

Les ioctl(2)s suivants renvoient des informations dans valeur. La syntaxe correcte est :

int value;
error = ioctl(unix_socket, ioctl_type, &value);

ioctl_type peut être :

• SIOCINQ Renvoie la quantité de données non lues en attente dans le tampon de réception. La socket ne doit pas être dans l'état LISTEN, sinon l'erreur EINVAL est renvoyée. SIOCINQ est défini dans <linux/sockios.h>. Une alternative est d'utiliser le synonyme FIONREAD, défini dans <sys/ioctl.h>.