Re: [PATCH v2 2/3] nl80211: Limit certain commands to interface owner

[Arend Van Spriel <arend.vanspriel@broadcom.com>]

On 6/21/2019 7:14 PM, Denis Kenzior wrote:
> 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?

hmm. I tried searching in memory... of my email client but to no avail. 
I somehow recalled that netlink multicast was not guaranteed to be 
delivered/seen by all listeners.

>> "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 ;)

That's just it, right. This is what Marcel calls the real environment, 
but is it. The nl80211 is a kernel API and should that mean that there 
must be a managing daemon locking down APIs for other user-space tools 
to use. If I want a user-space app to show a radar screen with 
surrounding APs using scanning and FTM nl80211 commands it seems now it 
has to create a new interface and hope the resources are there for it to 
succeed. Where is my freedom in that? If I am using such an app don't 
you think I don't accept it could impact the managing daemon.

>> 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 ;)

Probably. One of my concerns was about NL80211_CMD_CONNECT event, but 
checking nl80211_send_connect_result() it seems to just send it to the 
mlme multicast group regardless SOCKET_OWNER use.

>> 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?

Not saying that. Just saying that the "real environment" is in the eye 
of the beholder and it would be nice if there was a way to opt out, but 
Marcel seems strongly opposed to it. So there seems no point in 
scratching that itch and come up with a patch.

Regards,
Arend