Re: NM 0.9 asks for PK auth without need

[Dan Williams <dcbw redhat com>]

On Fri, 2011-10-07 at 15:43 +0200, Ludwig Nussel wrote:
> Ludwig Nussel wrote:
> > 802.11x connections that are configured to always prompt for the
> > password also always require polkit authentication (bgo#646187).

So the PK stuff is a mix of permissions and historic configuration.
First off, network configuration is potentially a privileged operation
since you have a lot of power to screw up the machine.

But storing your WPA PSK in your user session doesn't make a ton of
sense since it's required by everyone who connects to the network. In
contrast to a VPN password or a EAP password, which are specific to your
user, not to the machine (typically).  Windows and Mac OS X both make
WiFi PSK networks system-wide, so NM's previous behavior also didn't
match up with common expectations.

But of course, to create a system-wide WiFi network, you need to be able
to edit system config files, so that means we should require some
permission to create the network and to request the password when
showing a UI.  Perhaps that's why Windows never shows you the password
again after the initial connection :)

So when creating a new wifi network, you first need to authenticate to
create the network in the first place.  That gets creating without the
PSK since the applet doesn't necessarily want to include a ton of
complex code that checks what specific passwords might be required.
Instead, it waits for NM to ask the applet what is required.  Then the
applet throws up a dialog, but since users want to see any old passwords
(since this case is no different than the "password is wrong" case)
another request is triggered to read the secrets so we can populate the
UI with the old key.  Of course it's a new network, so that key isn't
there yet.  But there's no way to know that without requesting it,
really.

Obviously the secret could be stored in the user session and be visible
to the creating user only; but that kills the feature of system-wide
connections by default, which should be doing for most network types
(excluding VPN and possibly 3G).  That's essentially what 0.8 and
earlier did, and we had reasonable requests to change that.

The question has been asked before of why we don't just let people have
system config permission by default in 0.9.  That's because there might
be old connections that were created before when users didn't have
system config permission by default, and it seems somewhat insecure to
suddenly allow access to those previously protected connections on an
upgrade.

There are probably ways to reduce the PK spammage, and I hope there are,
and I'm very interested in figuring out how we can do that.  But this
also could be handled better at the PolicyKit level; perhaps we should
simply default to auth_admin_keep or auth_self_keep?  That should kill
the need for the second dialog, I think.  Does that make a difference in
the usability?

Dan

> Here's a potentially embarrassing patch to fix or rather work around
> the issue. Improvements welcome, I don't really know the first thing
> about NM :-)
> 
> After struggling with the code for some hours I think there are
> several problems that make this situation complicated to fix though:
> - NM does not know whether a secret is (intentionally) not in the
>   config file. It just looks at gobject properties that don't know
>   why they are at their default value.
> - there doesn't seem to be a flag that tells NM whether a connection
>   is just being set up for the first time. Ie there is no need to
>   ask for auth again until the setup phase is complete.
> - I wonder whether the general concept of suddenly prompting the
>   user for passwords/passphrases (with potential PK popup) after the
>   initial setup phase is a good idea. It might be better and less
>   annoying to simply fail the connection attempt and require the
>   user to manually use the edit dialog.
> 
> cu
> Ludwig
> 
> _______________________________________________
> networkmanager-list mailing list
> networkmanager-list gnome org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list