Shared connection asks for root password on every reconnect.

I have a WIFI connection to a WPA-router. When I allow that all users can connect to this network, I have to enter the root password. So far, so good. But on next connection, e.g. after a S2RAM, it asks again for the root password.
I raised https://bugs.kde.org/show_bug.cgi?id=359842 for this, but this was rejected as ‘polkit settings issue’. But that seems to be an issue in the standard…

Does anyone have this issue as well and if not, can you share your (working) settings?

Hi DocB,

on old installs this is not happening

on the latest install it is, but it is not consistent

sometimes to get a wifi connection the root password needs to be entered twice and also the wallet password,
other times only the root password is asked for once

all seems to depend on the settings of auto connect, and allow all users access

wolfi123 has stated his is due to kde4 programs needing kwalletmanager and kde5 programs needing kwalletmanaager5

today kwalletmanager was tried but without success, hence no sync between kwalletmanager and kwalletmanager5

this is just to confirm you are not alone

cheers

config:-

2. Mär 09:53:48 CET 2016
System:    Host: hp-17-p105ng.home Kernel: 4.1.15-8-default x86_64 (64 bit) 
           Desktop: KDE Plasma 5.5.4 Distro: openSUSE Leap 42.1
Machine:   System: HP product: HP Notebook Mobo: HP model: 8130 v: 25.13 Bios: American Megatrends v: F.14 date: 12/08/2015
CPU:       Quad core AMD A6-6310 APU with AMD Radeon R4 Graphics (-MCP-) cache: 8192 KB 
           clock speeds: max: 1800 MHz 1: 1400 MHz 2: 1000 MHz 3: 1800 MHz 4: 1200 MHz
Graphics:  Card: Advanced Micro Devices [AMD/ATI] Mullins [Radeon R4/R5 Graphics]
           Display Server: X.Org 1.17.2 drivers: ati,radeon (unloaded: fbdev,vesa) Resolution: 1600x900@60.0hz
           GLX Renderer: Gallium 0.4 on AMD MULLINS (DRM 2.42.0, LLVM 3.7.0) GLX Version: 3.0 Mesa 11.0.8 Direct Rendering: Yes
Network:   Card-1: Broadcom BCM43142 802.11b/g/n driver: wl 
           Card-2: Realtek RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller driver: r8169

Hi Keellambert
thanks for your confirmation!

the double password-entry for kwalletmanager is a known issue.

Up to now I was consistently only asked for the root password.
Quite strange that the maintainer states that my settings are freaked up. IMO it is a more general problem.

Hi DocB,

On three other laptops and a PC reliant on wifi there is not a problem so it looks hardware specific

have you tried from a new use account? that would verify if it is your settings

I share your opinion and feel its a more general problem

this laptop is brand new (now 4 days old), purchased without an OS, so nothing should be messed up

cheers

This looks like the problem that I described in a blog post Another look at NetworkManager and Tumbleweed.

That was for Tumbleweed. But the latest updates to Leap 42.1 might have introduced that problem there.

I describe the work-around. Basically, install "NetworkManager-gnome (which contains “nm-applet”). You can fix this with “nm-applet”. In my experience, you can probably fix it with XFCE or MATE or Icewm. For Icewm, you would have to start “nm-applet” (from the command line is fine). And you would have to start a polkit deamon (using “/usr/lib64/libexec/polkit-kde-authentication-agent-1” should be fine).

Opensuse bug 938510 is related.

If this is the same bug, then I don’t see it as a polkit bug. Rather it is a NetworkManager client bug (calling polkit with the wrong information). It is being treated as changing a shared connection, which reasonably requires root. But it should instead be treated as making a connection, which should not require root.

After further investigation – yes, it is the identical problem.

I see that “libKF5NetworkManagerQt6” was updated in the last couple of days. That’s probably the change causing this new behavior.

If you setup a shared connection before then, it should be fine. If you have not shared the connection with other users, it should be fine. But if you have shared a connection since that update, you will probably see the problem described in the OP.

If you change it back to no longer a shared connection, then it will be easier to use. If you want it to be a shared connection as before this update, then I only know how to fix that using “nm-applet”. If you have XFCE or LXDE or MATE installed, you can probably fix it there. Otherwise, install “NetworkManager-gnome” and run “nm-applet” in an Icewm session. You might also need to run a polkit client (not sure of that). And you will be prompted for the root password once or twice while fixing it.

You have to edit the connection. Go to the connection security tab. Re-enter the network key. At the right of that line, you can click on a tiny icon and set it to “store the password for all users”. After that it should work the way that you wanted.

It is particularly related to allowing all users access. If you turn that off, then it should be back to only needing the kwallet password.

wolfi123 has stated his is due to kde4 programs needing kwalletmanager and kde5 programs needing kwalletmanaager5

I don’t think that’s right, but it could complicate the issue. I do suggest using “kwalletmanager5” to set “kwallet” to stay open, so that you are only asked for the wallet password once per session.

Apparently, it is actually “plasma-nm5”. And zypper logs show the last update of that as Feb 20 here (it might have been updated in the repos a day or two earlier). When I tested a month earlier, the problem did not exist in Leap, though it did exist in Tumbleweed.

I added a comment to the KDE bug report.

hi nrickert,

thx, nm-applet in iceWM did as described, now back to normal

the icon mentioned now reads “store the password only for this users” and then when selected three options are shown,
one of which is “store the password for all users”

cheers

I’m glad you have it working.

In my opinion, the KDE folk made a bad decision here. They need to admit their mistake and fix it. At present they are being stubborn.

Bad decision?
Sorry, but asking for the root password on connecting/disconnecting is not a decision by the KDE develpers.
There really must be something wrong on the OP’s system.

I use shared connections here since ever (on KDE4 and Plasma5), and it never asks for the root password when trying to connect/disconnect, only for changing the settings.
I’m using 13.2 though, not Leap, but the KDE (and plasma-nm5 in particular) is the same.

No, there is nothing wrong with the OP’s system. Or, at least, nothing that is involved here.

The bad decision was to store the network key in kdewallet, instead of having it stored centrally by NetworkManager. Other desktops have it stored centrally. And it works much better.

For example, if I setup the network connection in Gnome (even a connection for a single user), it still works in KDE (same user). But if I setup the connection in KDE, it doesn’t work in Gnome. (You can even test that in your 13.2 system, if you have Gnome or XFCE installed, or even with Icewm running “nm-applet” and a polkit client).

The workaround for this KDE problem was to set the connection to be shared. But now they have broken even that in Plasma 5.

I use shared connections here since ever (on KDE4 and Plasma5), and it never asks for the root password when trying to connect/disconnect, only for changing the settings.
I’m using 13.2 though, not Leap, but the KDE (and plasma-nm5 in particular) is the same.

Yes, that works. They did not screw up as badly with 13.2.

Are you really using the same “plasma-nm5”? I’m using 5.5.4-6.3 here. I think that was updated late Feb. Before that, using 5.4.3-3.2, the problem did not occur in Leap. And note that “LibKF5NetworkManagerQt6” was also updated recently (about 3 days ago), and perhaps that update is related to the change.

When you try setting up a shared connection with a fully updated Leap or with NetworkManager, you will run into exactly the same problem (unless it is fixed by then).

If you have an external drive available, try connecting that to your laptop, and install Tumbleweed or Leap. If Leap, fully update before you set your WiFi connect to shared. Then switch it to shared, and see what happens.

For a “shared connection” (formerly known as “system connection” the network key is stored centrally (by NetworkManager).

Only for a user connection kwallet is used.
The old plasmoid-networking did support storing it in plain text in the config file as well, but this option has been removed (for IMHO good reasons).

Or am I misunderstanding something here?

Are you really using the same “plasma-nm5”? I’m using 5.5.4-6.3 here.

Yes.
Actually I’m on 5.5.5 now though (but when I tried this it was with earlier versions), which will be released as update for Leap as well soon.

When you try setting up a shared connection with a fully updated Leap or with NetworkManager, you will run into exactly the same problem (unless it is fixed by then).

I cannot try at the moment because I have no wireless here (using a wired Ethernet connection).
But I did try in the past, and it worked.
You need to enter the key in the connection editor though, but IIRC you cannot even click on “OK” unless you do so.

In any case, if the root password is requested for connecting, something is indeed going wrong. (changing the configuration does require the root password in openSUSE’s default polkit rules)
In the end, plasma-nm(5) is just a frontend to NetworkManager. And NetworkManager asks polkit whether the action is allowed. It’s polkit then that asks for the root password if necessary (according to its rules).

Doesn’t mean that there might not be a bug in plasma-nm5 though.

As a first step to investigate, it would be helpful to know what exact polkit rule forces the root password request. This can be seen in the “Details” in the password dialog.

No, sorry, but this is false.

It was true for opensuse 13.2, and it was true for Leap when released. It was already false for Tumbleweed when I tested this in January (see this blog post dated Jan 16). It is false for Leap after recent updates.

The current behavior for Leap and Tumbleweed, is that the network key for a system connection is in KDEwallet. When you first login to KDE, you are prompted for the root password (by polkit) for authorization to supply the network key for a shared connection, and you are prompted to open kwallet. I think the root request comes first, though that’s from memory. There is a central configuration file in “/etc/NetworkManager/system-connections”, but the network key is not being stored there when the shared connection is setup in KDE. The key is still stored centrally (as a line in that configuration file) if the connection is setup in Gnome, XFCE, etc.

If you had already setup the shared connection before the recent Leap updates, then the key is already stored centrally so you won’t run into this problem. If you now make a connection shared with Leap or with Tumbleweed, you will run into exactly this problem.

Or am I misunderstanding something here?

Yes. You are basing this on old knowledge. Your previous experience is no longer relevant.

Actually I’m on 5.5.5 now though (but when I tried this it was with earlier versions), which will be released as update for Leap as well soon.

I have not tried it with 5.5.5. I suppose I could install “krypton” or “argon” on an external drived connected to my laptop, and test this if you think it important. My suspicion is that it will be the same as I have been seeing in my tests with 5.5.4.

In any case, if the root password is requested for connecting, something is indeed going wrong. (changing the configuration does require the root password in openSUSE’s default polkit rules)

Yes, I agree. It seems to be using the wrong polkit rule. It is using the rule for changing a system connection. But supplying a network key does not change the system connection unless key is saved centrally (in the definition file for the connection). Since the key is only provided for the one-time connection, a different polkit rule should be used.

So, in my opinion, storing the key locally was a bad decision. But, given that decision, the polkit rule being used is wrong, and that is clearly a bug.

Doesn’t mean that there might not be a bug in plasma-nm5 though.

This changed recently on Leap. As far as I know, there hasn’t been a NetworkManager change, though there is an update waiting for me now. It looks to me as if “plasma-nm5” and “LibKF5NetworkManagerQt6” are the only things that have recently changed that might conceivably be involved.

I expect that the relevant change in “plasma-nm5” was to retain the key in kwallet, and not ask NetworkManager to store it centrally when making a system connection.

As a first step to investigate, it would be helpful to know what exact polkit rule forces the root password request. This can be seen in the “Details” in the password dialog.

I’m pretty sure that it is the rule to change a system connection. But that’s from memory. I never wrote that down. To me, the real problem is storing the network key by user (i.e. in kwallet) instead of storing it centrally.

If you want, I can delete all defined connections, set it up again, then check the “Details” (and write it down this time).

If this really is the case, then it cannot work at all IMHO, and you would be right that the “KDE folks” made a bad decision.
But as mentioned, I cannot test it at the moment.

Yes, I agree. It seems to be using the wrong polkit rule. It is using the rule for changing a system connection. But supplying a network key does not change the system connection unless key is saved centrally (in the definition file for the connection). Since the key is only provided for the one-time connection, a different polkit rule should be used.

Well, it’s not plasma-nm’s (or the KDE developers’) decision which polkit rule is used.
It’s NetworkManager’s (or its developers’) decision.

Changing the key for an existing connection is apparently a configuration change.
And changing the configuration of a “system” connection does need root permissions for a “system” connection. That’s defined as such in (openSUSE’s) polkit rules.

I’m pretty sure that it is the rule to change a system connection. But that’s from memory. I never wrote that down. To me, the real problem is storing the network key by user (i.e. in kwallet) instead of storing it centrally.

But requiring the root password for changing a system connection is independent from the place where the password is stored.

Though as I said, I agree that it would be a bug if the system connection’s key would be stored (only) in the user’s kwallet by plasma-nm. As this cannot work IMHO.

At this point, I cannot confirm nor decline this is the case though (it wasn’t when I last tried).
I can only test this next weekend…

I’ll look forward to when you are able to test this.

A further note.

I have the argon live iso on a USB (original release version). So I booted that in my laptop and setup a network connection. Then I made it a shared connection.

I then rebooted. On plasma startup, I could see what looked like a polkit window open and close – it was probably asking for the root password, and closed when it discovered that root did not have a password. I was then prompted for opening kdewallet, after which the network connected.

Then I looked at the file config file in “/etc/NetworkManager/system-connections”. And the network key was not in that file.

The “plasma-nm5” version appears to be 5.5.90git*.

Incidentally, I tried “Terminal - Super User Mode” to look at that file. But it opened in ordinary user mode. (It seems to work as expected in standard Leap).

Yeah. Apparently it wanted to have the root password, but as it is empty the dialog just disappeared again.

Incidentally, I tried “Terminal - Super User Mode” to look at that file. But it opened in ordinary user mode. (It seems to work as expected in standard Leap).

The unstable konsole package still missed the “Root Shell” profile unlike the stable ones.
I noticed that and submitted a fix over a week ago:

It should be on the latest image, you probably used an older one?

Yes, this was the original Argon image, and not updated.

Ok, then at least this should be fixed by now. :wink:
If not, we need a rebuild of the Argon image…

Although, that’s off-topic of course.