6
votes

I'm running a client/server application on Red Hat Enterprise using ZMQ for message passing. The IPC socket used to associate a client with the server is implemented using a Unix domain socket.

If user A starts the server process, it seems like only clients started by user A can connect to and communicate over that socket. Our project requires that the clients be able to be run by different users, so this is a major sticking point.

The socket is located at /tmp/ipc_assoc with default 755 permissions. chmod 777 does not fix the problem. chown userB allows user B to access the socket, but user A then loses access. Not even root can access the socket. There is no ACL or SeLinux in use on the machine.

Is this typical behavior for Unix domain sockets? Has anyone figured out how to work around it?

4

4 Answers

4
votes

chmod(s.sun_path, 0777); after listening to the socket.

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);
2
votes

Temporarily alter the umask:

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 */
}

Of course, this is a bad idea if you're using threads.

1
votes

With some assistance from the ZMQ mailing list, I have made a work around. It's ugly, but seems to work consistently.

I had to make a subdirectory under /tmp and chmod 777 it. The server now creates the socket in that new folder. It also programmatically chmod 777 the socket. Now, as long as the server is run as root, any user can run a client and talk to the server.

I don't know why UNIX domain socket behave this way, but it sure is annoying.

0
votes

Have you tried adding UserA and UserB into a common user group?