Re: NM 0.9 asks for PK auth without need

[Dan Williams <dcbw redhat com>]

On Tue, 2011-10-11 at 17:14 +0200, Ludwig Nussel wrote:
> 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.

Yeah, though I'd hope we can rely on that.  Basically, my suggestion
here would be to use _keep, and make it explicit that stuff isn't
expected to be as smooth if you just use auth_admin/auth_self.  If you
do, that's your problem, since that's just dumb.  I think the defaults
for keeping the auth are reasonable.

But, we *also* can make the change for lock/unlock button in the secrets
dialog so that we don't request PK auth again unless the button gets
pressed.  These two things should fix most occurrences of this, right?

One other thing to think about: creating a new wifi network for
sharing :)  Not a common action, but this one actually requires *two* PK
requests: one for checking whether you are allowed to share via wifi,
and the second to create the connection.

Dan