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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ