2. EL 7
  3. man-pages-es
  4. unix(7)

Scroll to navigation

UNIX(7) Manual del Programador de Linux UNIX(7)

NOMBRE

unix, PF_UNIX, AF_UNIX, PF_LOCAL, AF_LOCAL - Conectores para la comunicación local entre procesos.

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.

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).

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).

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".

ERRORES

No hay suficiente memoria.
Se ha llamado a connect(2) con un objeto conector que no está escuchando. Esto puede ocurrir cuando no existe el conector remoto o el nombre de fichero no es un conector.
Se ha pasado un argumento inválido. Una causa común es olvidar asignar AF_UNIX al campo sun_type de las direcciones pasadas o que el conector se encuentre en un estado inválido para la operación aplicada.
Se ha invocado una operación orientada a conexión sobre un conector no orientado a conexión o se ha intentado usar la opción de "datos fuera de orden".
El protocolo pasado no es PF_UNIX.
Tipo de conector desconocido.
El tipo del conector remoto no coincide con el tipo del conector local (SOCK_DGRAM contra SOCK_STREAM)
La dirección local seleccionada ya está en uso o el objeto conector del sistema de ficheros ya existe.
Se ha llamado a connect(2) sobre un conector ya conectado o se ha especificado una dirección de destino en un conector conectado.
La operación del conector necesita una dirección de destino pero el conector no está conectado.
Se ha cerrado inesperadamente el conector remoto.
Se ha cerrado el conector remoto de un conector orientado a conexión. Si se ha activado, también se enviará una señal SIGPIPE. Esto se puede evitar pasando la opción MSG_NOSIGNAL a sendmsg(2) o a recvmsg(2).
La dirección de memoria de usuario no es válida.
El emisor ha pasado credenciales inválidas en struct ucred.

La capa de conectores genérica, o el sistema de ficheros al generar un objeto conector en el sistema de fichero, pueden producir otros errores. Vea las páginas de manual adecuadas para más información.

VÉASE TAMBIÉN

recvmsg(2), sendmsg(2), socket(2), socketpair(2), cmsg(3), capabilities(7), socket(7)

2 diciembre 2002 Página man de Linux