netdev - Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect for sockets in accept(3)

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]

Message-ID: <562A631B.6060207@oracle.com>
Date:	Fri, 23 Oct 2015 17:40:59 +0100
From:	Alan Burlison <Alan.Burlison@...cle.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	Casper.Dik@...cle.com, Al Viro <viro@...IV.linux.org.uk>,
	David Miller <davem@...emloft.net>, stephen@...workplumber.org,
	netdev@...r.kernel.org, dholland-tech@...bsd.org
Subject: Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect
 for sockets in accept(3)

On 23/10/2015 17:19, Eric Dumazet wrote:

>>> The AF_UNIX poll one? No, I don't have the means to do so, and in any
>>> case that's not a POSIX issue, just a plain bug. I'm happy to log a bug
>>> if that helps.
>
> BTW, there is no kernel bug here. POSIX poll() man page says :
>
> POLLOUT
>      Normal data may be written without blocking.
>
> If you attempt to write on a listener, write() does _not_ block and
> returns -1, which seems correct behavior to me, in accordance with man
> page.

Except of course data may not be written, because an attempt to actually 
do so fails, because the socket is in the listen state, is not connected 
and therefore no attempt to write to it could ever succeed. The only bit 
of the required behaviour that the current AF_UNIX poll implementation 
actually gets right is the "without blocking" bit, and that's only the 
case because the failure is detected immediately and the write call 
returns immediately with an error.

> socket(PF_LOCAL, SOCK_STREAM, 0)        = 3
> bind(3, {sa_family=AF_LOCAL, sun_path=@""}, 110) = 0
> listen(3, 10)                           = 0
> write(3, "test", 4)                     = -1 ENOTCONN (Transport endpoint is not connected)
>
> Could you point out which part of POSIX is mandating that af_unix
> listener MUST filter out POLLOUT ?

"A file descriptor for a socket that is listening for connections shall 
indicate that it is ready for reading, once connections are available. A 
file descriptor for a socket that is connecting asynchronously shall 
indicate that it is ready for writing, once a connection has been 
established."

If POSIX had to explicitly list every possible thing that 
implementations *should not* do rather than just those that they 
*should* do then it would be even more unwieldy than it already is.

And if what you are asserting is correct, why isn't the AF_INET 
behaviour the same as the AF_UNIX behaviour?

-- 
Alan Burlison
--
--
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