Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH v2 2/3] nl80211: Limit certain commands to interface owner
To:     Arend Van Spriel <arend.vanspriel@broadcom.com>,
        Johannes Berg <johannes@sipsolutions.net>
Cc:     linux-wireless@vger.kernel.org
References: <20190620220749.10071-1-denkenz@gmail.com>
 <20190620220749.10071-2-denkenz@gmail.com>
 <11852f40-67e5-9122-7d82-077bdd0b014a@broadcom.com>
From:   Denis Kenzior <denkenz@gmail.com>
Message-ID: <af810765-ba1a-c7ae-abe5-35eef72eb8ce@gmail.com>
Date:   Fri, 21 Jun 2019 12:14:01 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <11852f40-67e5-9122-7d82-077bdd0b014a@broadcom.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

Hi Arend,

On 06/21/2019 03:09 AM, Arend Van Spriel wrote:
> On 6/21/2019 12:07 AM, Denis Kenzior wrote:
>> If the wdev object has been created (via NEW_INTERFACE) with
>> SOCKET_OWNER attribute set, then limit certain commands only to the
>> process that created that wdev.
>>
>> This can be used to make sure no other process on the system interferes
>> by sending unwanted scans, action frames or any other funny business.
> 
> The flag is a good addition opposed to having handlers deal with it. 
> However, earlier motivation for SOCKET_OWNER use was about netlink 
> multicast being unreliable, which I can agree to. However, avoiding 

???  I can't agree to that as I have no idea what you're talking about 
:)  Explain?  SOCKET_OWNER was introduced mainly to bring down links / 
scans / whatever in case the initiating process died.  As a side effect 
it also helped in the beginning when users ran iwd + wpa_s 
simultaneously (by accident) and all sorts of fun ensued.  We then 
re-used SOCKET_OWNER for running EAPoL over NL80211.  But 'multicast 
unreliability' was never an issue that I recall?

> "funny business" is a different thing. Our testing infrastructure is 
> doing all kind of funny business. Guess we will need to refrain from 

So you're going behind the managing daemon's back and messing with the 
kernel state...  I guess the question is why?  But really, if wpa_s 
wants to tolerate that, that is their problem :)  iwd doesn't want to, 
nor do we want to deal with the various race conditions and corner cases 
associated with that.  Life is hard as it is ;)

> using any user-space wireless tools that use the SOCKET_OWNER attribute, 
> but how do we know? Somehow I suspect iwd is one to avoid ;-) I have yet 

I guess you will be avoiding wpa_s since that one uses SOCKET_OWNER too ;)

> to give iwd a spin, but this SOCKET_OWNER strategy kept me from it. 
> Maybe iwd could have a developer option which disables the use of the 
> SOCKET_OWNER attribute.

Okay?  Not sure what you're trying to say here?  I'd interpret this as 
"You guys suck.  I'm taking my ball and going home?" but I hope this 
isn't what you're saying?

Regards,
-Denis