Re: NM 0.9 asks for PK auth without need

[Ludwig Nussel <ludwig nussel suse de>]

Dan Williams wrote:
> 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.

ACK

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

Yes, I got that. It's fine that nm-applet doesn't make a difference
and just implements generic prompts for simplicity. The problem with
the polkit popup when asking for a 802.11x password for an existing
connection first and foremost really is just a bug of
has_system_secrets(). The patch I sent tries to fix that.

> 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 way NM 0.9 treats all connections as system connections is fine
in principle AFAICT. It just needs some fine tuning to prompt for PK
auth in the right moments IMO. Granting users privileges to edit
connections by default is not the solution.

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

You already rely on _keep when configuring new connections. Ie

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.

6 could be skipped because the user is already authenticated by 3
so you would not rely on PK's _keep.

To achieve that NM could store an extra key with the connection that
indicates that the connection is still incomplete and missing pieces
are supposed to be filled in by user XY.
Alternatively NM could use a special virtual connection (like the
"auto eth*" connections) during setup phase. When the connection is
successful it could convert it into a real one and actually save in
/etc only then¹.

Wrt wrong-password-dialogs you could avoid surprising PK popups by
showing the dialog in a read only view with an unlock button first.
Those popups are surprising because they are shown before the user
actually knows what the authentication is for.
However, even better might be to just avoid wrong-password-dialogs in
the first place. Just fail the connection.

cu
Ludwig

[1] That way of implementing it would probably also allow to probe
for other things, like e.g. IPv6 connectivity. Ie if there was no
IPv6 prefix announcement during setup NM doesn't need to wait for
one later either and therefore set the option to ignore v6.

-- 
 (o_   Ludwig Nussel
 //\
 V_/_  http://www.suse.de/
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)