Re: Add a SOCK_DESTROY operation to close sockets from userspace

["Maciej Żenczykowski" <zenczykowski@gmail.com>]

> What I object to is userspace making reachability decisions, not
> whether SOCK_DESTROY closes the socket in one way or the other.

Privileged userspace can already make these decisions today, whether
it is by killing processes with open sockets, or by turning interfaces
up and down or by reconfiguring the firewall and/or the routing
rules/tables, or by injecting spoofed TCP reset packets (via tap).
It's just *very* inconvenient to do and error prone.

Another example: privileged userspace could ptrace the userspace apps
and via code injection call close() on the app's behalf and reopen the
file descriptor to some null routed destination so it behaves like if
it was timed out / unreachable.

In general the statement that (appropriately privileged) 'userspace
should not be able to do something' is wrong - about the only
exception I can think of being crashing the machine or burning the
hardware.

The kernel's purpose in life should be to enable userspace to do things.

You make things too hard for people to do stuff via the kernel and you
end up with the kernel being out of a job.  People either implement
things entirely in userspace (userspace tcp stacks on raw sockets or
tap or udp) or switch to a different kernel or create a local fork...

I'm not saying the proposed solution is ideal (although honestly it
doesn't seem bad), but this problem does deserve a clean *kernel*
solution instead of insane userspace hacks or non vanilla Linux
patches which then propagate to a billion devices...