GNOME Bugzilla – Bug 623316
Prompt user for system connection secrets
Last modified: 2020-11-12 14:33:21 UTC
System connections have no mechanisms for prompting if a password is no longer correct or not provided. They should! I believe this will require DBus API changes to network-manager and changes to use the new API in network-manager-applet. I have a patch attached, but they may need some work. The first patch adds a new DBus interface for the NetworkManager daemon to call to get secrets (org.freedesktop.NetworkManagerSettings.Secrets). The second patch is to nm-applet to implement the interface and actually throw up the dialog. Not much work there, it just handles the DBus call and removes a lot of checks that were there to prevent that situation before. :)
Created attachment 165046 [details] [review] Adds DBus API for daemon to use
Created attachment 165047 [details] [review] Handles the new call in nm-applet
One thing my patches do not do, and they *should* is to not ask a non-privileged user for a password. Like, if they don't belong to the admin group or something. Right now, it gives every user the ability to change the system connection secrets, which is probably not desirable. I'm not currently working on that though.
It looks pretty good from 5,000ft; a few comments... First, we probably want a 'service_name' argument in the D-Bus call (and down the chain into the settings service interface and base class) to maintain consistency with various other calls like ActivateConnection; the only reason that the other GetSecrets call didn't require this argument was that it was a call on the Connection object, and thus we already knew what settings service provided it. In this case we really don't. Second, in git master we have an authentication framework we can use. The NMManager object has the 'user_net_perm' variable that we can use for this purpose. We should check that it is NM_AUTH_CALL_RESULT_YES and if so, we can ask the user for secrets. This implies that the system administrator has allowed this user to control networking at all. This is also the gate for the "Enable Networking" checkbox in the applet these days. This isn't perhaps as fine-grained as I'd like, but I'm not sure we want to request PolicyKit authorization right before we ask the user for the wifi password either. There are probably cases where admins want the user to be able to start/stop system connections (ie, allow network control) but not change them. That would require a new permission though, which we could implement fairly easily but obviously is more code. We need to keep binary compat as well; which means we can't re-arrange members in the public structures like in libnm-glib/nm-settings-interface.h; you had inserted the new member between two existing ones; we need it at the end. Likewise for symbol visibility we need to ensure that new functions like nm_settings_interface_get_secrets_for_connection() get added to libnm-glib.ver so they are actually usable. Can you test my attached patch out and update the applet patch to match the new D-Bus arguments? Thanks!
Created attachment 165071 [details] [review] updated get secrets for connection D-Bus call patch
Note there is on error in my patch where info->connection isnt' getting set; so keep that in mind when testing that out. Let me know!
Just a quick update to say I haven't entirely forgotten about this bug. I will help test your patch, just have been busy/forgetful.
Created attachment 171053 [details] [review] updated nm-applet patch Here's (finally) an updated version of the nm-applet patch built against your new API (which passes the session_name). It seems to work with two caveats: 1) The password prompt appears with a second password prompt to authorize the user to see the existing password. Kinda hoky. 2) It seems like it didn't always remember the password I gave it? Part of my testing was to screw up the password in /etc/NetworkManager/system-connections/* and restart NM, then try. I could connect alright after the prompt, but if I switched away and back, sometimes it would still prompt me. Seemed to remember it after a reboot though?
reopening as there is a new version of the patch
this bug would require reworking, and it's not clear that it
(In reply to Thomas Haller from comment #10) > this bug would require reworking, and it's not clear that it *hump*. I meant to say, the patch needs review and reconsideration. Which apparently didn't happen for the past 6 years :( Is this still relevant?
bugzilla.gnome.org is being shut down in favor of a GitLab instance. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/ Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).