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: <5628C558.2040402@oracle.com>
Date:	Thu, 22 Oct 2015 12:15:36 +0100
From:	Alan Burlison <Alan.Burlison@...cle.com>
To:	Al Viro <viro@...IV.linux.org.uk>
CC:	David Miller <davem@...emloft.net>, eric.dumazet@...il.com,
	stephen@...workplumber.org, netdev@...r.kernel.org,
	dholland-tech@...bsd.org, casper.dik@...cle.com
Subject: Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect
 for sockets in accept(3)

On 22/10/2015 05:44, Al Viro wrote:

>> It's been said that the current mechanisms in Linux & some BSD
>> variants can be subject to races
>
> You do realize that it goes for the entire area?  And the races found
> in this thread are in the BSD variant that tries to do something similar
> to what you guys say Solaris is doing, so I'm not sure which way does
> that argument go.  A high-level description with the same level of details
> will be race-free in _all_ of them.  The devil is in the details, of course,
> and historically they had been very easy to get wrong.  And extra complexity
> in that area doesn't make things better.

Yes, I absolutely agree it's difficult to get it right. Modulo 
undetected bugs I believe the Solaris implementation is race free, and 
if it isn't I think it's fair to say we'd consider that to be a bug.

>> , and the behaviour exhibited
>> doesn't conform to POSIX, for example requiring the use of
>> shutdown() on unconnected sockets because close() doesn't kick off
>> other threads accept()ing on the same fd.
>
> Umm...  The old kernels (and even more - old userland) are not going to
> disappear, so we are stuck with such uses of shutdown(2) anyway, POSIX or
> no POSIX.

Yes, I understand the problem and in an earlier part of the discussion I 
said that I suspected that all that could really be done was to document 
the behaviour as changing it would break existing code. I still think 
that's probably the only workable option.

>> I'd be interested to hear
>> if there's a better and more performant way of handling the
>> situation that doesn't involve doing the sort of bookkeeping Casper
>> described,.
>
> So would a lot of other people.

:-)

>> To quote one of my colleague's favourite sayings: Performance is a
>> goal, correctness is a constraint.
>
> Except that in this case "correctness" is the matter of rather obscure and
> ill-documented areas in POSIX.  Don't get me wrong - this semantics isn't
> inherently bad, but it's nowhere near being an absolute requirement.

I don't think it's *that* obscure, when I found the original shutdown() 
problem google showed up another occurrence pretty quickly - 
https://lists.gnu.org/archive/html/libmicrohttpd/2011-09/msg00024.html. 
If a fd is closed then allowing other uses of it to continue in other 
threads seems incorrect to me, as in the dup2() scenario I posted.

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