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. Reproducible: Always Steps to Reproduce: 1. share WIFI connection for other users on Laptop 2. 3. Expected Results: root password should only be entered once
Unfortunately it does not get better when you create the connection as root. In this case, for a normal user, it asks for the root password *and* the wifi credentials. Thats even worse then creating the entry per user. This feature is completely freak'ed up!
You seem to have something with rights. What's the output from: "qdbus --system --literal org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.NetworkManager.GetPermissions"
Run as normal user: docb@T520:~> qdbus --system --literal org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.NetworkManager.GetPermissions [Argument: a{ss} {"org.freedesktop.NetworkManager.network-control" = "yes", "org.freedesktop.NetworkManager.enable-disable-wwan" = "yes", "org.freedesktop.NetworkManager.settings.modify.own" = "yes", "org.freedesktop.NetworkManager.wifi.share.protected" = "auth", "org.freedesktop.NetworkManager.wifi.share.open" = "auth", "org.freedesktop.NetworkManager.enable-disable-network" = "yes", "org.freedesktop.NetworkManager.enable-disable-wimax" = "yes", "org.freedesktop.NetworkManager.sleep-wake" = "yes", "org.freedesktop.NetworkManager.enable-disable-wifi" = "yes", "org.freedesktop.NetworkManager.settings.modify.system" = "auth", "org.freedesktop.NetworkManager.settings.modify.hostname" = "auth"}] docb@T520:~>
I think that "org.freedesktop.NetworkManager.settings.modify.system" = "auth" is responsible for your problem.
(In reply to Jan Grulich from comment #4) > I think that "org.freedesktop.NetworkManager.settings.modify.system" = > "auth" is responsible for your problem. If you say so.....how was this set? Resp, how can I change it, and to what?
In /usr/share/polkit-1/actions/org.freedesktop.NetworkManager.policy you can try to change "defaults" section for "org.freedesktop.NetworkManager.settings.modify.system" action to what I have: <defaults> <allow_any>auth_admin_keep</allow_any> <allow_inactive>yes</allow_inactive> <allow_active>yes</allow_active> </defaults> But please, read the documentation about this, because I have never touched this configuration and I'm not sure about the correctness.
I had the following settings: <defaults> <allow_any>auth_admin_keep</allow_any> <allow_inactive>auth_admin_keep</allow_inactive> <allow_active>auth_admin_keep</allow_active> </defaults> Changing it to your settings did *not* fix the problem. Therefore reopening
Do not reopen this issue because it's not a problem in plasma-nm. Have you restarted your computer after you changed that?
(In reply to Jan Grulich from comment #8) > Do not reopen this issue because it's not a problem in plasma-nm. Have you > restarted your computer after you changed that? Yes, I did. If it is not a problem in Plasma, where is the problem then?
In your configuration. Is the output from the command above different?
Output looks equal: docb@T520:~> qdbus --system --literal org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.NetworkManager.GetPermissions [Argument: a{ss} {"org.freedesktop.NetworkManager.network-control" = "yes", "org.freedesktop.NetworkManager.enable-disable-wwan" = "yes", "org.freedesktop.NetworkManager.settings.modify.own" = "yes", "org.freedesktop.NetworkManager.wifi.share.protected" = "auth", "org.freedesktop.NetworkManager.wifi.share.open" = "auth", "org.freedesktop.NetworkManager.enable-disable-network" = "yes", "org.freedesktop.NetworkManager.enable-disable-wimax" = "yes", "org.freedesktop.NetworkManager.sleep-wake" = "yes", "org.freedesktop.NetworkManager.enable-disable-wifi" = "yes", "org.freedesktop.NetworkManager.settings.modify.system" = "auth", "org.freedesktop.NetworkManager.settings.modify.hostname" = "auth"}] As I did not change (except above, for this bug) any settings, I feel it is either an upgrade problem or an issue of rights in the default delivery
As I said, read some documentation about the polkit configuration, maybe you need to kill the polkit deamon first, I don't really know as I have never done this before.
Difficult one...openSUSE Forums report the same issue. On the other hand, I tried on a new installed, fully patched openSUSE 42.1, and there it worked as it should. and the permissions are the same as in comment 3
In my opinion, this should be reopened. I won't reopen because of comment 8, but I disagree with that comment. Firstly, this is specifically a plasma 5 issue. If the network connect is setup in Gnome or XFCE or MATE or LXDE, then the problem does not arise. If "nm-applet" is used as network client and the connection is setup with that client, the problem does not arise. When I tried running nm-applet in Plasma 5, I could not access it, so nm-applet has to be run elsewhere. Since it works with nm-applet (which is used in XFCE), then it cannot be a polkit problem. Rather, the plasma client does things differently and, in my opinion, wrongly. I have a blog post about this at: https://nwrickert2.wordpress.com/2016/01/06/another-look-at-networkmanager-and-tumbleweed/ Responding to comment 4 >I think that "org.freedesktop.NetworkManager.settings.modify.system" = "auth" is responsible for your problem. Yes, that's possible. But that's the wrong polkit rule. The user is just making a connection. The user is not changing a system connection. In my opinion, it should instead use "org.freedesktop.NetworkManager.network-control". As far as I know, it is a plasma issue to specify the appropriate rule. When the user first changed the connection to be a system connection, then "modify.system" was appropriate. But just connecting to an existing system connection does not modify the connection definition, so should be under the more general "network-control".
As I know, all other NM clients (in Gnome, MATE, XFCE) use NM libraries directly, we in KDE control NM over DBus. I think you need "modify.system" allowed because once you try to activate the connection then NM gets the secrets and update the connection with them so the connection is in some way modified. Oh and btw. regarding your blog, even in plasma-nm you have options to store the password to current user, all users or do not store it at all.
In reply to Neil Rickert from comment #14) > In my opinion, this should be reopened. I won't reopen because of comment > 8, but I disagree with that comment. ... > I have a blog post about this at: > https://nwrickert2.wordpress.com/2016/01/06/another-look-at-networkmanager- > and-tumbleweed/ Very interesting, thanks for the analysis! Your workaround is nothing for the average user. But your post confirms the issue. @Jan: Following your comment 15, opening the system.modify policy is IMO not a bad idea on a normal desktop system.
Sorry for reopening, but I experimented with this a bit, and there do seem to be some strange things going on, unrelated to the polkit rules setup. First of all, everything works fine when the wireless password is stored system-wide. Unfortunately there's a bug in Qt5 (fixed in 5.6) that prevents you to click on the disk icon in the "Wireless security" settings to change the password storage, you have to resize the window first to be able to. Not a bug in plasma-nm though, of course. If the password for the shared connection is stored in kwallet, and the password for the wallet is empty, everything works as expected too. There's no need to enter the root password, even if the wireless password is not stored yet and has to be asked when connecting. But: if the wallet is protected by the password, and the wallet has to be opened, the *root* password is requested (for *modifying* the shared connection). Of course, changing the polkit rules to allow modifying the connection would prevent that, but IMHO that's only a workaround. Oh, and what's especially strange: you can just cancel the polkit root password request without entering the root password. The connection will still be successfully established. So this root password request is bogus anyway. To me it looks that plasma-nm is indeed doing something wrong.
Thanks for reopening. I did not get any email for the recent comments. I think my ISP may be blocking KDE.org. So I have now changed the email address that I am using. (The same problem happened with the opensuse bugzilla).
After update to openSUSE Leap 42.2 I see a related issue in KDE 5.26.0: Once the network was disabled with the RF Kill switch, and it is turned on again, NetworkManager ( I assume) asks for root password on this connection again. This is strange, as the same network was already connected in the same session before. And - a user should never be asked for a root password for a shared connection.
Correction - happens as well after s2ram
*** Bug 362130 has been marked as a duplicate of this bug. ***
Unsubscribing user per abuse report.
Closing. There is nothing I can do about this problem in plasma-nm, it's a problem with your policy configuration.
Reopening as this still needs clarification IMO. Especially the latter part: > But: if the wallet is protected by the password, and the wallet has to be > opened, the *root* password is requested (for *modifying* the shared connection). > Of course, changing the polkit rules to allow modifying the connection would prevent that, but IMHO that's only a workaround. > Oh, and what's especially strange: you can just cancel the polkit root password request without entering the root password. The connection will still >be successfully established. > So this root password request is bogus anyway. > To me it looks that plasma-nm is indeed doing something wrong. AFAICT the bug is actually a design flaw: NetworkManager gets the general message to activate a connection, but as it has no secrets saved, it has to ask for them using the secret agent. This causes NM to ask for the "modify.system" privilege, although the user has direct access to the secret storage anyway.
It might be a problem in design, but definitely not in plasma-nm so please keep this bug closed and report your concerns to NetworkManager.