Re: Add a SOCK_DESTROY operation to close sockets from userspace

From: Hannes Frederic Sowa <hannes@stressinduktion.org>
To: Lorenzo Colitti <lorenzo@google.com>, Tom Herbert <tom@herbertland.com>
Cc: "Eric Dumazet" <eric.dumazet@gmail.com>,
	"David Miller" <davem@davemloft.net>,
	"Maciej Żenczykowski" <zenczykowski@gmail.com>,
	"Stephen Hemminger" <stephen@networkplumber.org>,
	"Linux Kernel Network Developers" <netdev@vger.kernel.org>,
	"Eric Dumazet" <edumazet@google.com>,
	"Erik Kline" <ek@google.com>, "Dmitry Torokhov" <dtor@google.com>
Subject: Re: Add a SOCK_DESTROY operation to close sockets from userspace
Date: Thu, 19 Nov 2015 23:38:01 +0100	[thread overview]
Message-ID: <1447972681.3063104.444798817.76BFD7A6@webmail.messagingengine.com> (raw)
In-Reply-To: <CAKD1Yr1ji7AP-YKJ5kG8xYhgksNbXKKKcLoQPRsEtN020Gb_0g@mail.gmail.com>

On Thu, Nov 19, 2015, at 23:33, Lorenzo Colitti wrote:
> On Fri, Nov 20, 2015 at 2:38 AM, Tom Herbert <tom@herbertland.com> wrote:
> >> I actually don't have an issue with killing from user space that much. I
> >> still recommend (and actually have started to look at it today) to add a
> >> new substate for TCP TIMEWAIT and don't have any issue if we block the
> >> socket for 60 seconds and send RSTs to all incoming data. This way we
> >> can solve the problem Florian indicated as well as this problem. Users
> >> can happily kill TCP connections then.
> >>
> > Neither do I have a problem with killing connections from userspace,
> > but we do have to acknowledge that this is a powerful and invasive
> > mechanism. I suggest:
> >
> > 1) We need transparency. If a third party kills a TCP connection then
> > the application should be informed of specifically that. This seems
> > easy enough to just pick an appropriate error number as I suggested.
> 
> I'm not wedded to ETIMEDOUT. If it means we can get this code
> upstream, then we can likely do the userspace work that is needed to
> ensure that applications respond correctly. Mot
> 
> > 2) We need constraints. This feature seems to be specific to a very
> > narrow use case. It is not at all clear to me if there are any
> > legitimate uses cases beyond Android, enabling this by default in the
> > stack creates a non-zero amount of risk and liability for abuse. It
> > seems like this should be an opt-in sort of feature, with a kernel
> > CONFIG or maybe opt-in per socket.
> 
> I am perfectly happy for this to be behind a config option.

Why? If it is an administrator only option it does not make sense to
hide it behind a sysctl. Applications using this interface could also
easily change the sysctl because they probably have the same privileges.
A Kconfig option seems to be not useful to me either.

> I do think this kernel functionality is useful in general, and as a
> linux-on-laptop user I wish it was available to NetworkManager as
> well, because I use Linux as well, but I think it will work for
> Android if this requires a per-socket opt in setsockopt. For other
> reasons we pipe all connected sockets through a userspace daemon
> anyway. (But please don't tell me that that daemon should keep state
> on *all* connected sockets it ever sees :-))

Exactly!