After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 660392 - Joining wireless networks requires admin privileges
Joining wireless networks requires admin privileges
Status: RESOLVED DUPLICATE of bug 646187
Product: NetworkManager
Classification: Platform
Component: Wi-Fi
0.9.x
Other Linux
: Normal normal
: ---
Assigned To: Dan Williams
NetworkManager maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2011-09-28 20:01 UTC by Michael Biebl
Modified: 2014-03-31 21:00 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Michael Biebl 2011-09-28 20:01:49 UTC
When creating new wireless network connections, NM requires admin privileges from the user. That means a PK dialog pops up in the user session, which is a rather annoying behaviour.

This is due to the fact, that in 0.9, wireless connections are system wide by default. 

Possible ideas:
1/ Make wireless connections not system wide by default
2/ Don't require admin privs for creating *new* connections but only when modifying or deleting existing ones (to avoid leaking passwords etc).


Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642136
Comment 1 Bin Li 2011-12-22 03:50:46 UTC
We also met this issue in openSUSE 12.1.

Cause it need the org.freedesktop.NetworkManager.setttings.modify.system permission.

If we allow this permission they will permit user to edit all the other connection. And maybe we need a more nice permission for every type of connection.

https://bugzilla.novell.com/show_bug.cgi?GoAheadAndLogIn=1&id=731812
Comment 2 Dan Winship 2012-04-04 15:14:13 UTC
(In reply to comment #1)
> If we allow this permission they will permit user to edit all the other
> connection. And maybe we need a more nice permission for every type of
> connection.

Are there scenarios in which it makes sense for a user to be able to connect to arbitrary wireless networks, but not be able to configure other types of network connections?
Comment 3 Yann Soubeyrand 2012-04-07 13:54:12 UTC
I'm not sure if it make sense for a normal user (not an admin) not to be able to create his own connections of other types than wifi.

On a laptop a normal user should be able to create his own connections of every type but not to configure or create global connections.

The right for a user to configure his own connections is already present in the policy-kit policies files brought by network-manager. The problem is just an user interface problem as the choice to create a non global connection is not present.

Bye!

Yann
Comment 4 Jiri Klimes 2012-04-12 10:45:35 UTC
Yeah, there are two policy-kit actions:
org.freedesktop.NetworkManager.settings.modify.system for all-user's connections
and
org.freedesktop.NetworkManager.settings.modify.own for "private" connections

To obtain current permissions, this can be run:
dbus-send --system --print-reply --dest=org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.NetworkManager.GetPermissions

Admins can adjust permissions in
/usr/share/polkit-1/actions/org.freedesktop.NetworkManager.policy
Comment 5 Pavel Simerda 2012-07-25 14:16:26 UTC
Works for me in current versions.
Comment 6 Michael Biebl 2012-07-25 18:03:11 UTC
Pav(In reply to comment #5)
> Works for me in current versions.

It is definitely not fixed in 0.9.4 and 0.9.6 rc2.

Which versions did you test?
Comment 7 Pavel Simerda 2012-07-27 01:38:11 UTC
Fedora's NetworkManager-0.9.4.0-9.git20120521.fc17.x86_64. It's probably distribution specific. Information about the source of the broken configuration?
Comment 8 Jiri Klimes 2012-07-27 07:41:31 UTC
Michael, so what does your PK configuration file look like? (/usr/share/polkit-1/actions/org.freedesktop.NetworkManager.policy)

Also, what is the output of:
$ nmcli nm perm
$ ck-list-sessions
Comment 9 Michael Biebl 2012-07-27 08:24:11 UTC
ttbomk fedora ships a distribution specific policykit rule to workaround that problem.

The command "nmcli nm perm" doesn't exist with NM 0.9.4.0 which is the latest stable release and that I'm currently running.
As for the output of ck-list-sessions: my session is marked as active and local, so this is not the problem.
The problem is, that 
<action id="org.freedesktop.NetworkManager.settings.modify.system">
requires <allow_active>auth_admin_keep</allow_active>.

I assume fedora overrides that somehow.
Comment 10 Jiri Klimes 2012-07-27 08:55:48 UTC
"nmcli nm permissions" has been added just after 0.9.4, it'll appear in 0.9.6 :)  
You can always use D-Bus GetPermissions call from #comment 4

Well, Fedora indeed tweaks the modify.system permission to allow it:
@@ -95,7 +95,7 @@
     <_message>System policy prevents modification of network settings for all users</_message>
     <defaults>
       <allow_inactive>no</allow_inactive>
-      <allow_active>auth_admin_keep</allow_active>
+      <allow_active>yes</allow_active>
     </defaults>
   </action>
So that explains the problem.

I'm not sure why it's set "auth_admin_keep" upstream. I guess Dan wanted to have more secure setting, and distros/admins are supposed to adapt it to their needs.
Comment 11 Michael Biebl 2012-07-27 09:09:06 UTC
(In reply to comment #10)

> I'm not sure why it's set "auth_admin_keep" upstream. I guess Dan wanted to
> have more secure setting, and distros/admins are supposed to adapt it to their
> needs.

I am indeed worried to simply change settings.modify.system to <allow_active>yes</allow_active> since then effectively everyone can read WPA passphrases (of other users), delete network connections etc.
On a single user system that is probably ok, but having this as default on a general purpose distribution like Debian is something I'm reluctant to do (speaking as package maintainer)

Requiring the admin/user to change that setting isn't great either.
Comment 12 Marius Kotsbak 2012-11-16 11:39:33 UTC
I tried this with a guest account in Ubuntu 12.10, and the issues I saw were:

1) "available to all users" option was as default on. It should be off as default for users that does not have right to add global connections.

2) If I try to save the connection set to be available to all users, I get an error if I cancel the authentication dialog, but it should not close the window. I lost my entered data. Because of 1) this is likely to happen; the user first try to add a connection and then discovers that the system wide option is set and wants to try again with a connection just for himself.
Comment 13 nodiscc 2012-11-16 12:43:40 UTC
Reverting "available to all users" option to off by default would solve this bug in a nice way.
Comment 14 Pavel Simerda 2013-10-01 20:05:36 UTC
Current status?
Comment 15 Dan Williams 2014-03-31 21:00:02 UTC
I'm going to dupe this to bug 646187, since they are tracking essentially the same issue.  NM does what it's told here, and clients (nm-applet, kde, gnome-shell, etc) can specify whether they want to use private/user-specific connections or not.

*** This bug has been marked as a duplicate of bug 646187 ***