Re: NM 0.9 asks for PK auth without need

[Ludwig Nussel <ludwig nussel suse de>]

Dan Williams wrote:
> On Tue, 2011-10-11 at 16:23 +0200, Ludwig Nussel wrote:
>> [...]
>> 1. user clicks on ESSID he wants to connect to
>> 2. nm-applet shows the new connection edit dialog and posts results to NM
>> 3. NM asks PK for auth
>> 4. NM creates the new connection without secrets and stores it in /etc
>> 5. NM starts the connection and detects missing secrets
>> 6. NM asks PK for auth to determine whether it's allowed to send
>>    existing system secrets to nm-applet
>> 7. NM asks nm-applet to prompt for secrets
>> 8. nm-applet sends secrets back to NM
>> 9. NM checks whether the auth at 6 was fine to determine whether to
>>    actually use the secrets the user sent.
>>
>> That could be further improved IMO.
>>
>> By exchanging 2 and 3 the users that are not allowed to administer
>> their machine would not even try to start setting up connections.
> 
> I tried to think of how this would happen but didn't get there.  Did you
> have any implementation thoughts here?  Ideally the applets wouldn't
> even let you do this (since they can ask whether they are allowed to
> perform the action too) since it's pointless to present choices to the
> user that are just going to be denied by NM.

No, I haven't looked at the actual implementation.

>> 6 could be skipped because the user is already authenticated by 3
>> so you would not rely on PK's _keep.
> 
> But I thought that's what _keep did for us already?  Basically, we still
> need to check authorization in NM, and I had assumed use of _keep would
> simply return "success" since PK should be tracking whether the user is
> authorized and for how long.  Would be somewhat odd if PK didnt' do this
> for us.  Unless we're not requesting the same permission in (3) and (6)?
> I didn't go check the code, but I *thought* it was still the same
> permission there, and thus that PK would simply return "authorized" for
> (6) because the user had already authenticated, and we specified _keep.

Yes, that works as long as noone changes auth_admin_keep to auth_admin.
So nothing wrong with the code if you rely on _keep.
I actually changed to auth_admin intentionally to find out where NM asks
PK while debugging the 802.11x annoyance. NM enters the exact same code
at step 5 as listed above if it needs to prompt for user owned secrets.
So hopefully users won't actually see this in practice.

> [...]
> But still, I'd think PK would handle the second request for us since the
> user already authenticated to add the connection in the first place...?
> And I thought the permissions were the same for the add connection and
> the get secrets requests (ie, modify.system).

That's how it works but personally I don't really trust it :-) AFAIK
_keep means polkit remembers the authorization for some unspecified
time. If the user needs longer than that (like distracted by a phone
call) PK would ask again.

cu
Ludwig

-- 
 (o_   Ludwig Nussel
 //\
 V_/_  http://www.suse.de/
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)