netdev - Re: why would EPIPE cause socket port to change?

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] [day] [month] [year] [list]

Message-Id: <20070123.223023.45743778.davem@davemloft.net>
Date:	Tue, 23 Jan 2007 22:30:23 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	herbert@...dor.apana.org.au
Cc:	shemminger@...ux-foundation.org, dean@...tic.org,
	netdev@...r.kernel.org
Subject: Re: why would EPIPE cause socket port to change?

From: Herbert Xu <herbert@...dor.apana.org.au>
Date: Wed, 24 Jan 2007 16:58:33 +1100

> On Tue, Jan 23, 2007 at 12:26:52PM -0800, Stephen Hemminger wrote:
> > 
> > Why does write cause an autobind? One would think that on a
> > SOCK_STREAM socket, the write should just fail with ENOTCONN
> 
> The autobind is occuring in generic code, i.e., inet_sendmsg().
> It will subsequently fail because the socket is not connected.

This is one of those situations where the -ENOTCONN might be
preferable, but we are not helping application writers one
iota because the bazillion existing kernels running out there
have the old behavior so app writers have to code for it
anyways.

So I think we should just leave things as they are.

If you read the language Richard Stevens uses when describing
both the usage and implementation of getsockname and
getpeername in BSD, he makes it very clear exactly what these
two interfaces are intended to be used for.

They are to be invoked in situations where the application
has no reason to know what the socket is bound to locally
or remotely, and there are two real cases:

1) determining the result of an auto-bind
2) finding the remote address/port of a socket obtained
   via a fork/exec

I'm sure there are some other minimally different variants,
but those are the two main cases.

This makes it doubly clear that uses such as the one in libnss-ldap
were totally unintended, and should be avoided since every single
OS behaves differently in this case. :-)
-
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