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]

Date:	Wed, 18 May 2016 22:05:55 -0600
From:	David Ahern <dsa@...ulusnetworks.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Lorenzo Colitti <lorenzo@...gle.com>,
	Subash Abhinov Kasiviswanathan <subashab@...eaurora.org>,
	Stephen Hemminger <stephen@...workplumber.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	netdev-owner@...r.kernel.org, David Miller <davem@...emloft.net>,
	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 9:47 PM, Eric Dumazet wrote:
> On Wed, 2016-05-18 at 21:02 -0600, David Ahern wrote:
>> 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.
>
> So, lets say the filter found 123456 sockets matching the filter, and
> 12345 could be killed
>
> What would be exit status of ss command ?

Again, I could care less if the exit status is 0 if the user is given "A 
request failed b/c operations is not supported" message. That is feedback.

>
> In this case, there is no black/white answer.
>
> It looks like you have specific needs, you should probably add an option
> to ss to have a specific behavior.
>
> But saying current behavior is 'wrong' is subjective.

You think it is ok to send a request to the kernel, the kernel says "I 
can't do it" and the command says nothing to the user? That is current 
behavior. How on Earth is that acceptable?

I believe my last proposal is that that user gets a single "I could not 
do what you asked" message and nice little summary:

N sockets closed
M sockets failed

If M = total number of sockets then perhaps there is a bigger problem -- 
like a config option is not enabled.