2010-08-11 7 views
6

Estoy ejecutando una aplicación cliente/servidor en Red Hat Enterprise usando ZMQ para el envío de mensajes. El socket IPC utilizado para asociar un cliente con el servidor se implementa utilizando un socket de dominio Unix.¿Sockets de dominio UNIX no accesibles entre los usuarios?

Si el usuario A inicia el proceso del servidor, parece que solo los clientes iniciados por el usuario A pueden conectarse y comunicarse a través de ese socket. Nuestro proyecto requiere que los clientes puedan ser ejecutados por diferentes usuarios, por lo que este es un importante punto de fricción.

El socket se encuentra en/tmp/ipc_assoc con 755 permisos predeterminados. chmod 777 no soluciona el problema. chown userB le permite al usuario B acceder al socket, pero el usuario A pierde el acceso. Ni siquiera root puede acceder al socket. No hay ACL o SeLinux en uso en la máquina.

¿Es este comportamiento típico para los sockets de dominio Unix? ¿Alguien ha descubierto cómo solucionarlo?

Respuesta

1

Con un poco de ayuda de la lista de correo ZMQ, he hecho un trabajo alrededor. Es feo, pero parece funcionar de manera consistente.

Tuve que hacer un subdirectorio en/tmp y chmod 777. El servidor ahora crea el socket en esa nueva carpeta. También programáticamente chmod 777 el zócalo. Ahora, siempre que el servidor se ejecute como root, cualquier usuario puede ejecutar un cliente y hablar con el servidor.

No sé por qué el socket de dominio UNIX se comporta de esta manera, pero seguro que es molesto.

+0

¿por qué funciona 777 mientras que 770 no? Estoy desconcertado, he puesto a ambos usuarios en el mismo grupo y no voy ... – knocte

0

¿Ha intentado agregar UserA y UserB a un grupo de usuarios común?

+0

Parece que todos ya están en el mismo grupo. –

+0

¿Es un enlace simbólico a otro archivo con diferentes permisos? –

+0

No, si ejecuta 'ls -l' en el socket, imprime" srwxr-xr-x ... ipc_assoc " –

4

chmod (s.sun_path, 0777); después de escuchar el zócalo.

domain = AF_UNIX; 
name = servname; 
port = -1; 

n = MakeLocalSocket(s); 
if (n == 0) { 
    fatal("can't create socket"); 
} 

unlink(s.sun_path); 

if (bind(fd, & s, n) < 0) { 
    fatal("can't bind socket"); 
} 

if (listen(fd, 5) != 0) { 
    fatal("can't listen to socket"); 
} 

/* UNIX domain sockets need to be mode 777 on 4.3 */ 
chmod(s.sun_path, 0777); 
+0

¿por qué funciona 777 mientras que 770 no? Estoy desconcertado, he puesto a ambos usuarios en el mismo grupo y no voy ... – knocte

+0

No estoy seguro. Sin embargo, de acuerdo con http://man7.org/linux/man-pages/man7/unix.7.html "POSIX no hace ninguna declaración sobre el efecto de los permisos en un archivo de socket, y en algunos sistemas (por ejemplo, BSD anteriores), los permisos de socket se ignoran. Los programas portátiles no deben confiar en esta característica para la seguridad ". – Homer6

+0

en realidad, resolví el problema: ¡el usuario que agregué al grupo tuvo que volver a iniciar sesión para que el cambio surta efecto! pero gracias por tu comentario – knocte

2

alterar temporalmente la máscara de usuario:

mode_t umask_ = umask(0000); /* let the socket be mode 0777 so that other users can connect */ 
int err = bind(fd, (struct sockaddr *)&unix_bind_addr, sizeof(unix_bind_addr)); 
umask(umask_); /* restore old umask (0777 is a pretty bad choice for normal stuff) */ 
if (err) { 
    /* handle bind error here */ 
} 

Por supuesto, esto es una mala idea si usted está utilizando hilos.

Cuestiones relacionadas