GNOME Bugzilla – Bug 751378
Non-admin users can't join new Wi-Fi networks
Last modified: 2015-07-29 12:30:40 UTC
Create a new user on your machine, make sure it isn't an admin. (if you create it with Settings, that means it must be a "Standard" account) Then log as this new user. Now try connecting to a **new** Wi-Fi network. That is, a network which has never been connected to on this machine. GNOME will ask for an admin password... Which you don't have, if you're a non-admin user. So non-admin users just can't connect to new Wi-Fi networks. ---- I think the problem here is that by default, GNOME sets the "Make available to other users" option, and that requires admin permissions. Unfortunately, there is no way to unset that option **before** joining a new network, because the preferences for a given network are only available **after** joining it at least once.
One possibility to fix this would be if the "Make available to other users" was unset by default for non-admin users. (assuming that's the only issue here) Another possibility would be to make the preferences for a given network accessible before joining it for the first time. (i.e the "gear" button on the SSID line)
(In reply to Mathieu Bridon from comment #1) > One possibility to fix this would be if the "Make available to other users" > was unset by default for non-admin users. (assuming that's the only issue > here) That sounds like a good solution to me.
I'll note that on Fedora, non-admin users can join new wifi networks just fine. That's because NetworkManager is built with the --enable-modify-system=yes configure switch, which sets the polkit policy to allow all user to make a network available to others. In polkit terms, that means: <action id="org.freedesktop.NetworkManager.settings.modify.system"> <description>Modify network connections for all users</description> <defaults> <allow_any>auth_admin_keep</allow_any> <allow_inactive>yes</allow_inactive> <allow_active>yes</allow_active> </defaults> </action> However, when using the default build options (which some other distributions might do), one gets: <action id="org.freedesktop.NetworkManager.settings.modify.system"> <description>Modify network connections for all users</description> <defaults> <allow_any>auth_admin_keep</allow_any> <allow_inactive>auth_admin_keep</allow_inactive> <allow_active>auth_admin_keep</allow_active> </defaults> </action> Which is why I encountered the bug on Debian, but couldn't reproduce it on Fedora. :) I'm working on a patch to GNOME Control Center to implement the solution Allan chose in comment 2.
Created attachment 306148 [details] [review] network: Only share a new wifi connection if the user is allowed to Making a new connection available to other users requires being an admin, or entering an admin password. If we enable that option by default for new connections, we effectively prevent non-admin users from connecting to new networks when they go to the coffee shop without their laptop admin.
We're going to need a similar patch for GNOME Shell, as Wi-Fi networks can be connected to from there as well. I'll try and cook up something if we agree on this one, first. :)
Review of attachment 306148 [details] [review]: ::: panels/network/net-device-wifi.c @@ +756,3 @@ if (!is_8021x (device, ap_object_path)) { + NMConnection *partial = NULL; + GPermission *permission = (GPermission *)polkit_permission_new_sync ( The cast isn't needed, polkit_permission_new_sync() already returns a GPermission. The indentation is also super borked. Please declare and assign the variables separately. We should probably use an async version as well, but we could live with that for now... @@ +762,3 @@ + + if (!allowed_to_share) { + NMSettingConnection *s_con = (NMSettingConnection *)nm_setting_connection_new (); Ditto.
(In reply to Bastien Nocera from comment #6) > Review of attachment 306148 [details] [review] [review]: > > ::: panels/network/net-device-wifi.c > @@ +756,3 @@ > if (!is_8021x (device, ap_object_path)) { > + NMConnection *partial = NULL; > + GPermission *permission = (GPermission > *)polkit_permission_new_sync ( > > The cast isn't needed, polkit_permission_new_sync() already returns a > GPermission. Indeed. > The indentation is also super borked. How so? > Please declare and assign the > variables separately. Will do in a new version of the patch. > We should probably use an async version as well, but we could live with that > for now... I can try that.
Created attachment 306152 [details] [review] network: Only share a new wifi connection if the user is allowed to Making a new connection available to other users requires being an admin, or entering an admin password. If we enable that option by default for new connections, we effectively prevent non-admin users from connecting to new networks when they go to the coffee shop without their laptop admin.
Created attachment 306155 [details] [review] network: Only share a new wifi connection if the user is allowed to Making a new connection available to other users requires being an admin, or entering an admin password. If we enable that option by default for new connections, we effectively prevent non-admin users from connecting to new networks when they go to the coffee shop without their laptop admin.
Created attachment 306170 [details] [review] network: Only share a new wifi connection if the user is allowed to Making a new connection available to other users requires being an admin, or entering an admin password. If we enable that option by default for new connections, we effectively prevent non-admin users from connecting to new networks when they go to the coffee shop without their laptop admin.
Attachment 306170 [details] pushed as df54973 - network: Only share a new wifi connection if the user is allowed to
Why is this specific to wifi connections? Shouldn't we do the same for creating ethernet profiles or mobile broadband connections and other type of connections? Afaics, the only other type of connection which an unprivileged user can create in g-c-c are VPN connections. Those are user-private and the passwords are agent owned, i.e. stored in gnome-keyring. So my other question would be, if for user-private connections the passwords should be agent-owned by default? This patch makes the WPA-PSK be stored system wide. Another bit that is missing, is support in gnome-shell, which also allows you create wifi connections directly.
(In reply to Michael Biebl from comment #12) > Why is this specific to wifi connections? > > Shouldn't we do the same for creating ethernet profiles or mobile broadband > connections and other type of connections? > > Afaics, the only other type of connection which an unprivileged user can > create in g-c-c are VPN connections. Those are user-private and the > passwords are agent owned, i.e. stored in gnome-keyring. > > So my other question would be, if for user-private connections the passwords > should be agent-owned by default? > This patch makes the WPA-PSK be stored system wide. > > Another bit that is missing, is support in gnome-shell, which also allows > you create wifi connections directly. Best file separate bugs, the one specific to this bug is fixed.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=696257 for the discussion in Debian which lead to creation of patches for g-c-c, gnome-shell and nm-applet to allow unprivileged users to create user-private connections. Unfortunately, those patches were never merged upstream and the one for gnome-shell and gnome-control-center no longer apply cleanly to current git. I'm posting them nonetheless for completeness sake. gnome-shell: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789697;filename=28_network_user_connections.patch;msg=12;att=1 gnome-control-center: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;msg=10;bug=789698;filename=11_network_user_connections.patch nm-applet: https://anonscm.debian.org/cgit/pkg-utopia/network-manager-applet.git/tree/debian/patches/Allow-to-create-connections-without-admin-privileges.patch While I'm pretty sure that I forwarded those patches upstream back then, I don't find the bug numbers anymore. So I'm happy to file new bug reports hoping to restart the process.
@ Michael Biebl You are probably looking for https://bugzilla.gnome.org/show_bug.cgi?id=646187 - there is a bunch of patches that you at debian and we at openSUSE carry