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>
 <af810765-ba1a-c7ae-abe5-35eef72eb8ce@gmail.com>
 <b1ae8df6-c8a7-e453-aad3-e31bb2e3bd60@broadcom.com>
From:   Denis Kenzior <denkenz@gmail.com>
Message-ID: <68b4e059-71ba-1b3e-3764-5d28280fe11e@gmail.com>
Date:   Fri, 21 Jun 2019 17:33:02 -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: <b1ae8df6-c8a7-e453-aad3-e31bb2e3bd60@broadcom.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

Hi Arend,

>>> "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.

I get it.  But on the flip side, should the managing daemon accept you 
messing with it? I mean there is a definite associated cost here, 
whether it is stuff crashing, having to account for extra corner cases 
and race conditions, giving out erroneous results, etc.

As Marcel pointed out, the proper solution is to do this via some 
diagnostic interface on the managing daemon, so it can properly manage 
such requests to not interfere with whatever else is going on.

By the way, the above would be generally useful to many people, so if 
you have some code lying around... ;)

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

I guess the question is, what do you want this for?  If you want this 
for pure manual testing and accept the consequence of the managing 
daemon crashing, giving erroneous results or being otherwise confused? 
If you're fine with the above, I don't see a problem with such a patch.

Regards,
-Denis