netdev - Re: [PATCH iproute2] ss: Tell user about -EOPNOTSUPP for SOCK

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: <4ca62c9f-4d19-4dd1-0d8c-c2cfe17c0443@cumulusnetworks.com>
Date:	Wed, 18 May 2016 21:02:32 -0600
From:	David Ahern <dsa@...ulusnetworks.com>
To:	Lorenzo Colitti <lorenzo@...gle.com>,
	Subash Abhinov Kasiviswanathan <subashab@...eaurora.org>
Cc:	Stephen Hemminger <stephen@...workplumber.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	netdev-owner@...r.kernel.org, David Miller <davem@...emloft.net>,
	Eric Dumazet <eric.dumazet@...il.com>,
	Maciej Żenczykowski <zenczykowski@...il.com>,
	Tom Herbert <tom@...bertland.com>
Subject: Re: [PATCH iproute2] ss: Tell user about -EOPNOTSUPP for SOCK_DESTROY

On 5/18/16 6:55 PM, Lorenzo Colitti wrote:
> On Wed, May 18, 2016 at 3:35 AM, <subashab@...eaurora.org> wrote:
>> Would it be acceptable to have a separate column which displays the result of the sock destroy operation per socket.
>> State    ... Killed
>> ESTAB         Y
>> TIME_WAIT     N
>
> Fine by me, but... what problem are we trying to address? People who
> compile their own kernels and don't turn CONFIG_INET_DIAG_DESTROY, and
> then are confused why it doesn't work? Seems like we could fix that by
> turning CONFIG_INET_DIAG_DESTROY on by default. CCing the people who
> commented on the original SOCK_DESTROY patch to see if they have
> opinions.

The problem is proper feedback to a user. If the kernel supports an 
action but the action is not enabled the user should get some message to 
that fact. Doing nothing and exiting 0 is just wrong.

>
>> If it is not supported from kernel, maybe print U (unsupported) for this.
>
> In current code there is no way to distinguish U from N because in
> both cases the error will be EOPNOTSUPP. It's certainly possible to
> change SOCK_DESTROY to return something else (e.g., EBADFD) to
> indicate "kernel supports closing this type of socket, but it can't be
> closed due to the state it's in". In hindsight, perhaps I should have
> done that from the start.
>
> Regardless, we still have the problem of what to do if the user says
> "ss -K dport = :443" and we encounter a UDP socket connected to port
> 443. Options:
>
> 1. Silently skip. if the tool prints something, it means it closed it.
> 2. Abort with an error message.
> 3. Skip the socket and print an error every time this happens.
> 4. Skip the socket and print an error the first time this happens.
>
> Personally I still think #1 is the best option.

5. Print an error the first time and a summary at the end.

If the filter matches N sockets and all N fail with UNSUPPORTED give the 
user a message saying that all failed due to unsupported error which 
could mean the CONFIG option is not enabled or it could mean the sockets 
can not be forced closed.