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) _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list