connect() with unix-domain socket and full backlog

Question

When the listening backlog is full for STREAM unix-domain sockets, connect(2) fails on most systems with ECONNREFUSED. It would be preferable for it to return EAGAIN.

The reasoning is that it is highly useful to be able to distinguish between the two cases of dead socket (node exists in filesystem, but no process listening anymore) and the case of full backlog. I ran into this problem when porting some Linux software which has some code to clean up dead sockets, but it's a security vulnerability if the code can be tricked into deleting sockets by spamming them to fill up their backlog.

Only Linux returns EAGAIN; AIX, Solaris and Darwin follow BSD behaviour (just tested on each).

POSIX doesn't list EAGAIN as a possible return code from connect() (link), so there may be some compliance issue here.

What's the best route to get everyone to change in line with Linux? I could go and file a bug report with Oracle, Apple, a FreeBSD PR, and fight it out on the mailing lists of each organisation. Or should I pester someone in a standards body (Austin group)? Is it even advisable to try and get everyone to change here, even though the advantage is clear?

I'm voting to close this question as off-topic because it seems to be about the process of petitioning for a change to a POSIX standard, rather than about programming. — Useless, Jan 20 '17 at 10:41

score 2 · Answer 1 · answered Dec 20 '18 at 23:14

2

Whether or not you attempt to change the standard, or change how vendors have implemented connect(), I would argue from the point of view of the software, it wouldn't make any difference. ECONNREFUSED and EAGAIN should both be treated as a retry.

Distinguishing between the two cases may allow you to write a more specific diagnostic message on the client, but the retry logic should be the same. Even if the listener doesn't currently exist, it may eventually exist, so a retry should be attempted.

try_again:
    rc = connect(s, (void *)&addr, sizeof(addr));
    if (rc == 0) return connect_succeeded(s, &addr);
    switch (errno) {
    case EAGAIN:
    case ECONNREFUSED:
        if (should_try_again(retries++)) {
            goto try_again;
        }
        break;
    case EINTR:
        goto try_again;
    default:        
        break;
    }
    return connect_failed(s, errno);

answered Dec 20 '18 at 23:14

jxh

69,070
8
110
193

1

From the _client's_ point of view, it makes no difference which is returned... but for the server it's a big difference! When starting up, you want to detect dead socket files (where the listening process has gone), so that you can rm the socket, which relies on being able to detect whether the process is currently running. A lockfile would maybe be a better way of doing that - but this is some legacy software (unfortunately) so we needed a way to detect if the socket is dead or not. A more informative error would help in this case. – Nicholas Wilson Jan 04 '19 at 17:26
1

@NicholasWilson The reason my answer was client specific was because the question focused on `connect` behavior, which is typically a client side API. On linux systems, I avoid filesystem based sockets, and use abstract sockets instead. On non-Linux POSIX systems, I would probably opt for TCP over an internal interface (loopback). That is, my servers avoid this problem implicitly. If I had to deal with pathname sockets, I would use a parent process to launch the server, and to manage the pathname socket lifetimes base on the child process lifetimes. – jxh Jan 04 '19 at 18:05

score 0 · Answer 2 · answered Jul 21 '21 at 17:04

Like with most things, if you can convince the source to make the move, then all the users will have to comply. So having POSIX fix the issue is certainly what would be best. Then all implementations will have to comply.

Another solution is to use the system on which it works. i.e. only use Linux machines (in this case). Also with Linux you can tweak the kernel and make it work one way or the other (which is also doable with BSD).

Now, my opinion on the matter, it seems to me that the main issue here would be a rogue process attempting to open a socket to receive messages instead of the intended service. My question would be: how often does that happen?

If you use a system similar to systemctl, you will have one and only one instance of the service running. If you are attempting to open the AF_UNIX socket at that point in your service, you really are the only one trying to do so. Therefore, deleting the file is a non-issue.

If you allow rogue software to run on your system (i.e. it is public and you have many users with access, like in the old days when people would telnet to a server), then maybe you need to use a TCP or UDP connections instead.

Finally, if another software is able to open that AF_UNIX socket, I think that you're in trouble anyway since your service can be running while that rogue software (1) deletes your socket, (2) bind()'s anew, (3) your new clients are now talking to that rogue software, not your service, even though you are still running and listening for connections... on a hidden file socket. (Note that old clients will continue to talk with your service, any client that reconnects will talk to the rogue software).

So... where is your issue?

connect() with unix-domain socket and full backlog

2 Answers2