Disable SO_REUSEPORT for unix sockets

[e-nomem]

Because of the fix for CVE-2024-57903, the linux kernel started returning an error if an attempt is made to set the SO_REUSEPORT socket option on non-inet/inet6 sockets.

In gunicorn, if reuse_port is set to True and one of the bind addresses is a unix socket, this causes the arbiter to hang on newer kernels.

[pajod]

Thanks. What is the advantage of failing silently? The admin specifically requested it. We should let them know, no?

If they specified a mix of UNIX and INET sockets on the command line / config, I imagine we can safely assume that was by mistake, and if they combined INET socket on cmdline/config yet passed some bound UNIX socket via systemd.. that is broken anyway, because the Arbiter.start won't pick up both anyways. (Also: Could this patch break some edge case outside the intersection of isinstance(sock.getsockname(), tuple) and sk_is_inet(sk)?)

---

If there is an argument for silencing the discrepancy between requested config and applied settings, then the config help text should say so.

[e-nomem]

Thanks. What is the advantage of failing silently? The admin specifically requested it. We should let them know, no?

I guess, but doesn't that code already silently skip if the SO_REUSEPORT attribute is missing (I'm guessing if the kernel is older than v3.9 when the option was added...) even if it was explicitly requested in the config?

If they specified a mix of UNIX and INET sockets on the command line / config, I imagine we can safely assume that was by mistake, [...]

I don't think that's a safe assumption. I discovered this issue after a kernel upgrade in a situation where the configuration specified binding to both unix:/run/gunicorn/gunicorn.sock and 127.0.0.1:8080 and I think that's valid.

[...] and if they combined INET socket on cmdline/config yet passed some bound UNIX socket via systemd.. that is broken anyway, because the Arbiter.start won't pick up both anyways.

I can't speak to the systemd socket activation interactions. My application runs in a containerized environment without systemd.

(Also: Could this patch break some edge case outside the intersection of isinstance(sock.getsockname(), tuple) and sk_is_inet(sk)?)

I have no idea if any other address family returns names that are tuples 😅 I think the only way to sneak them into the system is via systemd socket activation though because the gunicorn code will only open sockets in one of the 3 'normal' address families of INET, INET6, and UNIX.

If there is an argument for silencing the discrepancy between requested config and applied settings, then the config help text should say so.

Agreed. Regardless of if this PR is merged, the docs should be updated. I guess it really comes down to deciding if attempting to bind to both a unix and inet socket at the same time is valid. If it is, we should silently skip setting the option (and maybe log the skip). If it is not valid, we should error out and fail. The latter seems like it would be a breaking change.

[pajod]

doesn't that code already silently skip if the SO_REUSEPORT attribute is missing

Fair.

docs should be updated [..] and maybe log the skip

In favor of both. (but not drafting any right now, given the already numerous unfinished docs changes)

I discovered this [..] binding to both unix:/run/gunicorn/gunicorn.sock and 127.0.0.1:8080 and I think that's valid.

One place restricted by filesystem permissions, another by netfilter rules.. easy to create a dangerous hole, when the WSGI app stays in the same networking namespace and can be tricked into connecting back to itself - yet expects only some reverse proxy able to. Not really in scope for this PR though: if someone was using it, well then it is valid. And perfectly reasonable for your fix to respect that.

any other address family returns names that are tuples

No useful scenario on any platform I care about - just the first remotely conceivable discrepancy I could come up with, as its the fall-through in stdlib. Unless I make some progress in having Github CI verify the wonderful world of non-Linux systems I am very wary of using Linux specifics to justify general changes (there is more than one SO_REUSEPORT..), thats all.

[e-nomem]

Looks like cpython has also decided to silently skip setting reuseport instead of erroring out: python/cpython#128933