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]

Date:	Thu, 29 Oct 2015 16:01:31 +0000
From:	David Holland <dholland-tech@...bsd.org>
To:	Alan Burlison <Alan.Burlison@...cle.com>
Cc:	David Holland <dholland-tech@...bsd.org>, Casper.Dik@...cle.com,
	Al Viro <viro@...IV.linux.org.uk>,
	David Miller <davem@...emloft.net>, eric.dumazet@...il.com,
	stephen@...workplumber.org, netdev@...r.kernel.org
Subject: Re: [Bug 106241] New: shutdown(3)/close(3) behaviour is incorrect
 for sockets in accept(3)

On Thu, Oct 29, 2015 at 03:18:40PM +0000, Alan Burlison wrote:
 > On 29/10/2015 14:58, David Holland wrote:
 > >ISTM that the best way to do this is to post a signal to the thread so
 > >accept bails with EINTR, at which point it can check to see if it's
 > >supposed to be exiting.
 > 
 > Yes, you could use pthread_kill, but that would require keeping a list of
 > the tids of all the threads that were using the FD, and that really just
 > moves the problem elsewhere rather than fixing it.

Hardly; it moves the burden of doing stupid things to the
application. If as you said the goal is to shut down all threads
cleanly, then it doesn't need to keep track in detail anyway; it can
just post SIGTERM to every thread, or SIGUSR1 if SIGTERM is bad for
some reason, or whatever.

 > >Otherwise it sounds like the call you're looking for is not close(2)
 > >but revoke(2). Last I remember Linux doesn't have revoke because
 > >there's no way to implement it that isn't a trainwreck.
 > 
 > close(2) as per specified by POSIX works just fine on Solaris, if that was
 > the case everywhere then it wouldn't be an issue. And for cases where it is
 > necessary to keep the FD assigned because of races, the dup2(2) trick works
 > fine as well.

close(2) as specified by POSIX doesn't prohibit this weird revoke-like
behavior, but there's nothing in there that mandates it either. (I
thought this discussion had already clarified that.)

Note that while NetBSD apparently supports this behavior because
someone copied it from Solaris, I'm about to go recommend it be
removed.

-- 
David A. Holland
dholland@...bsd.org
--
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