[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKD1Yr1Z8BzW-M+agO-b4Lo8PE8OAR3yedtzvwgLoX2tOYHx3g@mail.gmail.com>
Date: Wed, 18 Nov 2015 13:23:02 +0900
From: Lorenzo Colitti <lorenzo@...gle.com>
To: Tom Herbert <tom@...bertland.com>
Cc: Linux Kernel Network Developers <netdev@...r.kernel.org>,
Eric Dumazet <edumazet@...gle.com>, Erik Kline <ek@...gle.com>,
Maciej Żenczykowski <maze@...gle.com>,
Dmitry Torokhov <dtor@...gle.com>
Subject: Re: Add a SOCK_DESTROY operation to close sockets from userspace
On Wed, Nov 18, 2015 at 12:56 PM, Tom Herbert <tom@...bertland.com> wrote:
>> The patch series only implements SOCK_DESTROY for TCP sockets,
>> but the mechanism can be extended to any protocol family that
>> supports the sock_diag interface.
>>
> I assume that SIOCKILLADDR was restricted to only closing connections
> related to add addresses going away, but SOCK_DESTROY seems to allow
> arbitrarily killing connections without publicized cause.
Closing connections on deleted IP addresses is the main use of
SIOCKILLADDR, but the ioctl also supports closing all connections on a
userspace-provided IP address.
However, those semantics are not enough in some cases. For example:
when a VPN client connects, for security reasons (e.g., to make it
harder for on-link attackers to attack cleartext apps), traffic from
unprivileged applications is no longer permitted on non-VPN
interfaces. All unprivileged traffic is routed over the VPN.
Currently, existing TCP connections just hang, which typically annoys
the user. It would be better if we had the ability to close those
connections with SOCK_DESTROY.
SIOCKILLADDR cannot do that because it is inappropriate to
indiscriminately kill TCP connections that are not on the VPN - if
nothing else, one of those TCP connections could be the one that is
providing the VPN itself.
> Minimally, the application should get at
> least get a clear error that the local host administratively killed
> the connection, ETIMEDOUT does not provide that.
I don't know why ETIMEDOUT was chosen (we've been running this since
2008), but I think it's because:
1. All Internet applications have to be prepared to receive ETIMEDOUT
on TCP sockets.
2. ETIMEDOUT is the error that those applications would have gotten
anyway if they had waited a few minutes.
It's certainly possible to use something other than ETIMEDOUT, though
I don't know what error code would be appropriate. Perhaps we can make
it configurable by the caller.
--
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
Powered by blists - more mailing lists