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: <20151027.064228.237119117273824839.davem@davemloft.net>
Date:	Tue, 27 Oct 2015 06:42:28 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	Alan.Burlison@...cle.com
Cc:	Casper.Dik@...cle.com, viro@...IV.linux.org.uk,
	eric.dumazet@...il.com, 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)

From: Alan Burlison <Alan.Burlison@...cle.com>
Date: Tue, 27 Oct 2015 10:52:46 +0000

> an implicit shutdown() it would mean that well-written applications
> that handled the scoping, sharing and reuse of FDs properly could just
> call close() and have it work the same way across *NIX platforms.

This semantic would only exist after Linux version X.Y.Z and vendor
kernels that decided to backport the feature.

Ergo, this application would ironically be non-portable on Linux
machines.

If portable Linux applications have to handle the situation using
existing facilities there is absolutely zero value to add it now
because it only will add more complexity to applications handling
things correctly because they will always have two cases to somehow
conditionally handle under Linux.

And if the intention is to just always assume the close() semantic
thing is there, then you have given me a disincentive to ever add the
facility.
--
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