Re: windows [Re: Review of gnio, round 2]

[Dan Winship <danw gnome org>]

On 05/11/2009 03:47 AM, Alexander Larsson wrote:
> On Sun, 2009-05-10 at 10:53 -0400, Dan Winship wrote:
>> But if you bind() and then connect() (eg, like the rcmd/rsh/rlogin
>> suite) then maybe you don't want SO_REUSEADDR. (And looking at the glibc
>> source for rresvport(), it doesn't use SO_REUSEADDR, and instead just
>> keeps trying different ports at random until it either succeeds or gets
>> an error other than EADDRINUSE.) I'm not sure if there are use cases for
>> bind+connect that don't involve prehistoric "authentication" models...
> 
> I don't know how rcmd/etc work, do they require a specific source port
> for the connection?

They require a source port < 1024. This is how you prove to the remote
host that it can trust you, because you can only bind that port if
you're root. (Seriously, this is how the world used to work...)

Anyway, given the use case Simon described (in which automatically using
SO_REUSEADDR on a client socket would be a security hole), I think
setting SO_REUSEADDR on outgoing sockets is probably more-or-less always
bad.

I'm thinking making g_socket_bind() take a "gboolean reuseaddr" is a
good compromise. This puts the option in the application author's face
so they can't accidentally not think about it (and the docs can just say
"if you don't know otherwise, then you always want this set for server
sockets and you never want it set for client sockets"). But it still
leaves possible all the same operations the underlying API does.
(Simon's example gives a case of where being able to bind and connect in
two separate steps is important. There might be cases where being able
to bind and listen separately are important too, in which case we
wouldn't want to just move the bind() call into g_socket_listen() as I'd
suggested before.)

-- Dan