netdev - Re: binding UDP port 0 with SO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 1 Aug 2012 21:38:53 +0200
From:	"Tobias S. Josefowitz" <t.josefowitz@...il.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	netdev@...r.kernel.org
Subject: Re: binding UDP port 0 with SO_REUSEADDR

On Wed, Aug 1, 2012 at 9:02 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> And why are you using SO_REUSEADDR on UDP unicast sockets ?

Simple. This happens in a "scripting" language. The wrapper code
assumes that it is better to set SO_REUSEADDR than not (which might be
argued, but backwards-compat can be nice) and at the time the code was
written the author must have assumed that even if the 'user' aka
programmer wants to bind to port 0, SO_REUSEADDR doesn't hurt, because
port 0 implicitly meant "please, a free one".

> I mean, this is exactly saying " By using this REUSEADDR, I am allowing
> this port being used by another process, even from another user"

I know. Still, while binding port 0 means "give me any port", I'm
quite sure most people would assume they get a free one. And maybe,
for whatever reasons, you want to share your random port later and
need SO_REUSEADDR because of that. A usecase where someone wants a
randomly chosen free or used port does not come to my mind, though.

Of course, I'm not relying on the kernel to revert back, I adapted the
wrapper code I mentioned above. I still felt like mentioning that it
was kind of unexpected, that's all.

Best,

Tobi
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html