Re: defying original 4.3BSD sockets constraint

  Hi,

after more pondering around, I came to conclusion that TCP and UDP shall be
treated differently here.  First, the TCP already has the constraint relaxed
since 4658dc8325e0 in 2004.  Second, in TCP it is impossible to create a fake
connection.

I updated the test to cover all matrix of different cases:

https://reviews.freebsd.org/D56707

As you see, with SO_REUSEADDR a TCP socket will always succeed.

Given that every book starting from Stevens and down to an LLM generated how-to
on the Internet recommends to set SO_REUSEADDR before bind(2), I bet almost
100% of software does it.  I can't find any practical use case for an
application to actually want that bind(2) fails in the presence of its own old
sockets.  If such application existed it would use classic BSD option
SO_REUSEPORT, which is gratious unlike SO_REUSEADDR.  This SO_REUSEPORT was
available since 4.3BSD and not a single application ever used it, which ended
up Linux adding a completely different meaning to this string value in 2013.

And let's recognize that SO_REUSEADDR was never meant to be a security feature.

So my suggestion is that a TCP socket will behave as if SO_REUSEADDR is already
set on it. Here is the review:

https://reviews.freebsd.org/D56726

The review itself has more text then this email.

For the UDP the connection theft is possible, if you pre-setup a connected
socket before bind(2).  And looking into the matrix in the D56707, I think, we
are doing the right thing.  With existing conflicting connected socket bind(2)
would return EADDRINUSE.  But if you set SO_REUSEADDR, the conflict would be
ignored.  But if the conflicting socket belongs to a different user, then
bind(2) will fail even with SO_REUSEADDR set.

-- 
Gleb Smirnoff