SINOPSIS

#include <sys/socket.h>
#include <sys/un.h>

unix_socket = socket(PF_UNIX, type, 0);
error = socketpair(PF_UNIX, type, 0, int *sv);

DESCRIPCIÓN

La familia de conectores PF_UNIX (también conocida como PF_LOCAL) se usa para comunicar procesos en la misma máquina de manera eficiente. Los conectores Unix pueden ser o bien anónimos (creados mediante socketpair(2)) o bien estar asociados con un fichero de tipo conector. Linux también soporta un espacio de nombres abstracto que es independiente del sistema de ficheros.

Los tipos válidos son SOCK_STREAM para un conector orientado a conexión y SOCK_DGRAM para un conector orientado a datagramas que conserva las fronteras entre los mensajes. Los conectores Unix siempre son fiables y no reordenan los datragramas.

Los conectores Unix soportan el paso de descriptores de fichero o credenciales de proceso a otros procesos, usando datos auxiliares.

FORMATO DE LAS DIRECCIONES

Una dirección Unix se define como un nombre de fichero en el sistema de fichero o como una cadena única en el espacio de nombres abstracto. Los conectores creados mediante socketpair(2) son anónimos. Para conectores no anónimos la dirección del destino se puede configurar usando connect(2). La dirección local se puede configurar usando bind(2). Cuando un conector se conecta y no tiene todavía una dirección local, se genera automáticamente una dirección única en el espacio de nombres abstracto.

#define UNIX_PATH_MAX   108
struct sockaddr_un {
    sa_family_t  sun_family;              /* AF_UNIX */
    char         sun_path[UNIX_PATH_MAX]; /* nombre de la ruta */
};

sun_family siempre contiene AF_UNIX. sun_path contiene el nombre de ruta (terminado en cero) del conector en el sistema de ficheros. Si sun_path comienza con un byte cero se refiere al espacio de nombres abstracto mantenido por el módulo del protocolo Unix. La dirección del conector en este espacio de nombres viene dada por el resto de los bytes en sun_path. Dese cuenta que los nombres en el espacio de nombres abstracto no terminan en cero.

OPCIONES DE LOS CONECTORES

Por razones históricas estas opciones de los conectores se especifican con un tipo SOL_SOCKET, aunque sean específicas de PF_UNIX. Se pueden configurar con setsockopt(2) y leer con getsockopt(2) especificando SOL_SOCKET como familia del conector.

SO_PASSCRED

Habilita la recepción de las credenciales del proceso emisor en un mensaje auxiliar. Cuando esta opción está activa y el conector no está conectado aún, se genera automáticamente un nombre único en el espacio de nombres abstracto. Espera una bandera booleana entera.

MENSAJES AUXILIARES

Los datos auxiliares se envían y reciben usando sendmsg(2) y recvmsg(2). Por razones históricas, estos los tipos de mensajes auxiliares listados arriba se especifican con un tipo SOL_SOCKET, aunque son específicos de PF_UNIX. Para enviarlos, asigne al campo cmsg_level de la estructura cmsghdr el valor SOL_SOCKET y al campo cmsg_type el tipo. Para más información, vea cmsg(3).

SCM_RIGHTS

Enviar o recibir un conjunto de descriptores de fichero abiertos a/desde otro proceso. La parte de datos contiene un array de enteros con los descriptores de fichero. Los descriptores de fichero pasados se comportan como si hubieran sido creados con dup(2).

SCM_CREDENTIALS

Enviar o recibir credenciales Unix. Esto se puede usar para autenticación. Las credenciales se pasan como un mensaje auxiliar struct ucred.

struct ucred {
    pid_t  pid;  /* PID del proceso emisor */  
    uid_t  uid;  /* UID del proceso emisor */ 
    gid_t  gid;  /* GID del proceso emisor */ 
};

El núcleo comprueba las credenciales que el emisor especifíca. Un proceso con identificador de usuario efectivo 0 puede especificar valores que no coincidan con los suyos. El emisor debe especificar su propio identificador de proceso (a menos que posea la capacidad CAP_SYS_ADMIN), sus identificador de usuario, identificador de usuario efectivo o identificador de usuario de conjunto (a menos que posea la capacidad CAP_SETUID) y sus identificador de grupo, identificador de grupo efectivo o identificador de grupo de conjunto (a menos que posea la capacidad CAP_SETGID). Para recibir un mensaje struct ucred la opción SO_PASSCRED debe estar activa en el conector.

VERSIONES

SCM_CREDENTIALS y el espacio de nombres abstracto fueron introducidos en la versión 2.2 de Linux y no deberían usarse en programas transportables. (Algunos sistemas derivados de BSD también soportan el paso de credenciales, pero los detalles de implementación difieren.)

OBSERVACIONES

En la implementación de Linux, los conectores que son visibles en el sistema de ficheros respetan los permisos del directorio en el que están. Se pueden cambiar sus propietarios, grupos y permisos. La creación de un nuevo conector fallará si el proceso no tiene permisos de escritura y búsqueda (ejecución) en el directorio en el que se crea el conector. La conexión al objeto conector requiere permiso de lectura/escritura. Este comportamiento difiere del de muchos sistemas derivados de BSD que ignoran los permisos para los conectores Unix. Por seguridad, los programas transportables no deberían confiar en esta característica.

Ligar un conector con un nombre de fichero crea un conector en el sistema de ficheros que debe ser borrado por el invocador cuando no se necesite más (usando unlink(2)). Se aplica la semántica habitual de Unix detrás de una operación de cierre: el conector puede ser desligado en cualquier instante y será finalmente eliminado del sistema de ficheros cuando se cierre la última referecia a él.

Para pasar descriptores de fichero o credenciales necesita enviar/leer al menos un byte de datos.

Los conectores orientados a conexión del dominio Unix no soportan la noción de "datos fuera de orden".