System policy prevents modification of network settings for all users

[Phill Whiteside]

This seems like a regression? The screen shot is at http://thesii.org/Screenshot.jpg The nearest link I can find is from the forum area at http://ubuntuforums.org/showthread.php?p=11467777

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: network-manager 0.9.3.995+git201203152001.04b2a74-0ubuntu1
ProcVersionSignature: Ubuntu 3.2.0-20.32-generic 3.2.12
Uname: Linux 3.2.0-20-generic x86_64
ApportVersion: 1.95-0ubuntu1
Architecture: amd64
CRDA: Error: [Errno 2] No such file or directory
Date: Sun Mar 25 19:36:45 2012
IfupdownConfig:
 auto lo
 iface lo inet loopback
InstallationMedia: Lubuntu 12.04 "Precise Pangolin" - Alpha amd64 (20120323)
NetworkManager.state:
 [main]
 NetworkingEnabled=true
 WirelessEnabled=true
 WWANEnabled=true
 WimaxEnabled=true
ProcEnviron:
 LANGUAGE=en_GB:en
 TERM=xterm
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
SourcePackage: network-manager
UpgradeStatus: No upgrade log present (probably fresh install)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Carl Vancil (twist-f)]

I encountered this same message when I tried to add (1) an AT&T USB WLAN adapter, and then again (2) when I tried to add a PPTP-VPN profile.

Here's what I figured out though:
1. I use centrifydc to connect this system to Active Directory.
2. I am working from my office at work, and my domain controllers are on my home network, so it could not confirm that I was a member of the Domain Admins group.
3. /etc/group only had the bindings I had added for "root" and "%Domain\ Admins", so it didn't consider my cached AD-UID as a valid Admin user.
4. /etc/sudoers had a binding for "%Domain\ Admins", but since that group is currently unreachable due to being on a remote network that I would need to VPN to in order to auth against, the sudoers mechanism could not confirm that I had the rights to be performing root level functions.

Taking all of this into consideration, I managed somehow to sudo up and edit both files to add my ID explicitly. Then, when I retried to add my VPN profile, it worked! This time, rather than prompting me for root's password, I simply received a prompt to set my key-ring password instead, which I did, and was then able to VPN to my home network over the WLAN adapter.

Now, I may be on the wrong track here, and I made the explicit entry in /etc/sudoers identicle for my userID as what was already given for "root", but this worked for me to get this problem solved so that I could get on to other things.

I hope this helps someone else, or at least makes it a bit more clear for the developers as to what is going on.

[Mathieu Trudel-Lapierre (cyphermox)]

Carl:
There's no bug there: we're on purpose defaulting to system-wide connections since Oneiric. This means one will need administrator rights to be able to create system-wide connection profiles, which explains the popup. If you don't want to create a system-wide connection, you should still be able to uncheck the "Available to all users" checkbox and be able to create your new connection, which will only be availble to yourself. Obvioulsy, this also means that "available to all users" connections require adminitrative rights to be modified.

Phil,
Is there anything above that doesn't work with what you're seeing? I suspect the issue is simply that your user account is somehow not an administrator.

[Phill Whiteside (phillw)]

@ Mathieu, I'm about 3,000 miles from my lubuntu system on a course. But to answer your question, the 1st user created on installation is an admin user. This is simply because root is disabled by default. If the 1st account is not an admin, then there is a serious problem!

[Sean Brisbane (s-brisbane1)]

This issue has just tripped up one of our users too. Clicking 'cancel' to the 'system policy prevents modification of network serrings for all users' message appears to allow configurastion for an individual user, however, this is not at all obvious and I think most users will not realise that this is going on when 'all' they want to do is get an internet connection.

Would it be possible to add either additional text in the popup dialog box explaining that the user can 'click cancel to setup without administrative rights', since that is what they care about in this case. Possibly a tooltip explaining things to the technical user.

[amjjawad  (amjjawad)]

@Mathieu Trudel-Lapierre (mathieu-tl)

https://www.facebook.com/photo.php?fbid=319971734722540&set=o.284774574912703&type=1&ref=nf

I don't remember I had this issue before. Before, with 11.10, I used to Click "connect" on the Popup that asks for my Wifi Security Password NOT my admin password. Now, I need to see two popups instead of one which is bothering me to be honest. It's not convenient at all.

Thanks!

[amjjawad  (amjjawad)]

Un-check "Available to all users" has made it easier somehow because now, ONLY ONE Popup ( Wireless Network Authentication Required - Authentication required by wireless network) will show up upon any interruption or disconnection in the Wifi Signal and you just need to click "Connect", no need to re-type your Wireless Security Password since it's saved and no need to type your admin password since that popup (System policy prevents modification of network settings for all users) will not appear.

So, in order NOT to type the admin password, you just need to un-check "Available to all users" and that's it?

@Mathieu
Is that what do you mean by: "There's no bug there" at commend #4 ???

Thank you!

P.S.
I think that makes some sense to me now!

[unehed (unehed)]

This bug affects me because of the following scenario: At a school we have several laptops where we don't want to give out the root password nor the wireless key for our network. We do however want the pupils to be able to connect to other wireless networks when they take their computers home. If I give the pupils permission to create system-wide connections they can see the wireless key for the network I've configured.

The way I would like for it to work is that the default should be user specific connections without the need for higher privileges, ie. you would click the ssid, enter the key and then a dialog would pop-up asking you if you wanted this connection to be available to all users. If you clicked yes you would be prompted for the root password otherwise the wireless connection would only be available to you.

[Nate Gingras (suboscillator)]

I do not see a way around this for normal users. Clicking "Cancel" on the authenticate dialog puts the user back at square one.

The expected behavior is that you pick a network from the NM menu, it prompts for a key (if required), you enter the key and connect.

Currently non-admins can't connect to wireless networks. I have dozens of users with this issue, the only way around it was to allow them to add connections system-wide by overriding the polkit defaults, which I assume is a bad idea.

Why is NM defaulting to adding system-wide networks all of a sudden? Why is that even an option if we don't let non-admins do it?

[piviul (piviul)]

The same happens to me in ubuntu 12.04. There is no way to have a workaround?

Piviul

[piviul (piviul)]

I found a workoround: http://ubuntuforums.org/archive/index.php/t-1873477.html

Piviul

[TJ (tj)]

Mathieu Trudel-Lapierre (mathieu-tl) wrote on 2012-04-24: #4

Carl:
There's no bug there: we're on purpose defaulting to system-wide connections since Oneiric. This means one will need administrator rights to be able to create system-wide connection profiles, which explains the popup.

On this 12.04 install of Lubuntu, done from a minimal deboostrap followed by installing "lubuntu-desktop" the administrator users were manually put into the "adm" group.

There was no "admin" group created by any package - that is only done by the installer.

Therefore the solution was:

sudo addgroup admin
sudo adduser $USER admin

log-out and log-in again and the prompt for root password goes away.

[Carl Vancil (twist-f)]

Appreciate the comments, but they are not taking into account the scenario that affected my problem, as mine was different. In my case, it had nothing to do with 'admin' group itself, but rather how I had configured "Domain groups" and had omitted to explicitly add my Active Directory userID.

In all of the comments that were made in reply to my own, not a single one mentioned Active Directory or anything other than local accounts and groups. My case is not typical, so therefore your answers... while they would be correct in any other case, were incorrect in my case.

Notice that in item #4 of my original comment that the domain was currently not available to validate my userID as being a domain member. I don't use local accounts at all, except for root, and that ID is only used for system maintenance prior to setting up CentrifyDC to join the system to Active Directory. Needless to say, if the userid is an active directory ID rather than local, then you can do whatever you want to the local groups config and it won't matter unless you explicitely add the UserID rather than the group that user is a member of.

I've long since realized (since I posted that back in April) that I can simply setup my VPN connection from within the desktop environment for 'root', VPN into my home network where my domain controllers are located, at which point I can simply ssh as my Active Directory userID into 127.0.0.1 while the VPN connection is active to force an update of the cached credentials, and group cache. Essentially, mine was an issue where a remote group was inaccessible to allow proper validation of a local group that had the remote group nested as a member.

Otherwise though, I'm aware of the other ideas posted here, and my end results were that I simply added my Active Directory UserName as an explicit entry in /etc/group to all appropriate groups also occupied by 'root' & "%Domain\ Admins". I haven't had a problem like this since then.

I figured the issue had to do with a local group, and that any valid user account would need admin/sudo access in order to properly add any interfaces (ppp, vpn, etc), but it's a totally different scenario when you are using remote groups nested inside of local groups along with AD-auth, as opposed to local groups and local users explicitly. It basically adds a couple of dozen more pieces to the puzzle. :)

Anyways, I hope this doesn't come off as trolling, as that's certainly not my intent. My intent is simply to show an alternate scenario where the same problem occurs for similar but different reasons. In the end, the results are the same, for the same reason, but the components of the problem slightly vary.

Just to further complicate things, the installation on which I had dealt with this issue on is a "Sandisk 16GB USB stick", loaded with Ubuntu 12.04, that I use with an Acer Iconia Tab W500 (x86 tablet) so that I don't have to give up local disc-space to Ubuntu, which doesn't work quite perfectly with the touch-screen, hence why it's my secondary OS on that system rather than my primary. Fortunately, my builds on USB are basically identical to the builds I do on hard drives, on...

[Jesper (koudelkaa)]

This also affects me on lubuntu and I think it is a serious usability problem. Having to enter admin password is a confusing and unnecessary step for a average user and will make them annoyed. What is more is at least on lubuntu there seem to be no way to change so the default is to make a connection only for your user not all users.

The first thing a user will see is a scary message asking for administrator password to change for "all users" and it will make no sense for systems with only one user and also it makes no sense since no where in the interface did it say that it will create a connection for all users before showing the password screen.

Linus Torvalds made a good rant (although a bit strong) about this kind of issue when he tried to set up a computer for his daughter. https://plus.google.com/u/0/+LinusTorvalds/posts/1vyfmNCYpi5

[Sean Brisbane (s-brisbane1)]

The link posted by piviul contains a fix, though it requires every user to be in the adm group. My preferred fix is actually slightly different and just requires the person to be logged in. The following policy is applied on all mobile computers that I manage:

/etc/polkit-1/localauthority/30-site.d/10-users-edit-connections.pkla

[Allow all users to create network connections]
Identity=unix-user:*
Action=org.freedesktop.NetworkManager.settings.modify.system
ResultAny=auth_self
ResultInactive=no
ResultActive=yes

In case any ubuntu developers are reading this: It is annoying that the default policy forbids users to add or change network conections, as I think the security benefits are marginal. The current default policy is only correct on Ubuntu-based server's. I think it might be a better solution to have a more open default policy, but have a "server-security-policy" deb which gets installed by default with the ubuntu-server installs, and is available in the repos. This server-security-policy package/metapackage would pull in polkit policies that forbit users from editing connections. Obviously this leaves the door open to an even greater variation in security policy between desktops and servers as the need arises.

[Marius B. Kotsbak (mariusko)]

I tried this with a guest account now, and as expected I can't add system wide connections since I am not admin. 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.

Are there other issues that this? Then please upload screenshots. I was able to add a user connection.

[Marius B. Kotsbak (mariusko)]

Else, I suggest opening two new bug reports for each of my two issues above.

[Josep Pujadas-Jubany (jpujades)]

We have more than 300 notebooks with 12.04 LTS up-to-date. Users aren't sudoers and we made the following change...

At:

/usr/share/polkit-1/actions/org.freedesktop.NetworkManager.policy

Under the key

<action id="org.freedesktop.NetworkManager.settings.modify.system">

we changed the line:

<allow_active>auth_admin_keep</allow_active>

to:

<allow_active>yes</allow_active>

This permits to configure system connections without asking for the administrator's password.

However, we needed to upgrade network-manager and modemmanager for using some mobile broadband USB devices.

We upgraded from https://launchpad.net/~network-manager/+archive/trunk PPA and we lost our policy.

I agree if the user is not sudoer can't (by default) change system connections. But upgrades should test any changes made in policies.

Regards,

Josep Pujadas-Jubany

[Marius B. Kotsbak (mariusko)]

Which are the devices not supported? Are there bug reports for these?

[Marc Deslauriers (mdeslaur)]

The current behaviour is to modify system connections by default. You either need to be in the admin group, or you need to uncheck the box and create personal network connections. The current behaviour is as intended.

I am marking this bug as "Opinion" since there is a disagreement on whether or not a non-admin user can create system connections.

[unehed (unehed)]

The issue isn't that a regular user can't create system connections, the issue is that a regular user can't create ANY connections.

[Marius B. Kotsbak (mariusko)]

Yes, the issue should be solved by setting create system connection default off for people not being able to create system connections. I see Debian is patched to prompt for auth for doing that, so maybe that should be added too, and not disable the box completely because of that.

[Jerker Nordh (ajn)]

I have this bug aswell, how can a non admin priviliged user set up a connection for only themselves?

When I use an unprivledged account and click on a wireless network I'm asked for an administrative password, clicking cancel gives the error message about insufficient privliges, there is _no_ option to instead connect the network for the current user only.

Please explain to me what the opinion part of this is? There is no way for a regular user to connect to a new wireless network by clicking the network name, if you know all the id's and security settings it is possible to manually set it up and explicitely unchecking the "available for all users"-box, but this is not a how a normal user would connect to a network.

The current implementation is broken for regular users and makes it impossible for non-technically savy persons to use an ubuntu laptop with a new wireless connection.

[Benji (benjim)]

I'd like to pop up this issu again, especially because the bugfix is already clear (see post #19). It would be nice to change it and ship it out.

[Benji (benjim)]

I created a patch, maybe this helps?

[Jerker Nordh (ajn)]

Benji, I believe your patch is merely a work-around and doesn't follow the intended behavior as outlined earlier in this thread. Your patch seems to allow non-admin users to update the global settings, which I don't think is the correct solution.

I believe a proper solution would be that for an admin user an added network is automatically added to the system wide settings, but for a non-admin user it should merely create a temporary connection for that particular user. This shouldn't need any additional priviledges since the global configuration wouldn't have to be updated, and the user would as expected be able to connect to a wireless network without contacting their system administrator.

From reading this thread I believe the solution would be as "easy" as to to only make "Availbale for all users" the default if the user is in the admin group, if not the box should be automatically unchecked and there would be no need for an administrator password.

[Jerker Nordh (ajn)]

Related bug:
https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/1077982

[unehed (unehed)]

It seems the new related bug has been marked a duplicate of this one. (https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/1077982).

The thing is this bug is so often misunderstood I was happy to see the new bug report which was a lot more concrete. Can we at least get this one back to confirmed instead of opinion.

The "opinion"-status is just ridiculous.

There's also this bug: https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/1102354

I like the title of that one. No opinion there.

[Benji (benjim)]

As this and related bugs show:
Non-Admin users can't even connect to wireless networks, not already created. This is neither an opinion nor a "wish". Non-Admin users should at least be able to connect to wireless networks.
The cause of all effects here: Unchecking the "available to all users" box. But the intended functionally should be to click on a available network connection in the network-manager-applet and just connect to the wireless network. This doesn't work at all. Therefore I would consider it as a bug. Even if the intention is, not to allow normal users to modify system wide connections (which is pretty reasonable), the effects it causes are bugs, which lead (for non admin users) to the inability to use the uses in an adequate way.

Furthermore, according to the status, Debian and OpenSuse got the issue fixed.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "Patch" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

[Petar Bogdanovic (petar-smokva)]

The solution (whatever it ends up to be) should not enable unprivileged users to modify system connections. This might be obvious, but since a couple of users have happility reported success with sudoers- and/or default NM policy hacks, I thought it's worth mentioning.

[Kentling (kent-rasmussen)]

To futher comment #32, I think the point here is to distinguish between systems where
1. unpriveledged users should NOT be able to connect to or change which network a computer is connected to --like servers, and
2. systems where an unpriviledged user SHOULD be able to change which network a computer is connected to --like workstations managed by one person, and used by another. That is, an admin sets up the networks, but the user should be able to select which network to use in a given context, since there is no one else using the machine (in most use cases).

I don't see these both fitting nicely under one default; is there a setting somewhere that we might be able to utilise to switch between machines where admin wants unpriviledged users to be able to connect to the network, and machines where admin doesn't? Otherwise, it would seem we'll make one or the other upset.

[JoE (joehillen)]

Everyone here seems to be over-complicating the issue, so let me put it in simple terms.

My wife took her laptop away for the week. I get a call from her telling me she can't connect to any Wifi. I didn't want to give her my admin password, so she had to spend the whole week without a computer (no internet, means no computer to my wife). I had no idea she needed special privileges (there was no prompt or option for that when creating her account), and she had just been using the existing Wifi connection that I created when I first got the laptop, so we didn't know about the issue.

Needless to say, this is a MASSIVE USABILITY ISSUE. Linus had something to say about usability problems like this with Suse and his daughter. https://plus.google.com/+LinusTorvalds/posts/1vyfmNCYpi5

Now, I've spent the last several hours trying to figure out how to fix it, and none of the "solutions" are initiative, obvious, or findable using the UI. This is a non-issue on every other platform.

Users should be able to change network connections on desktops/laptops. PERIOD. BY DEFAULT. ALWAYS. I don't give a damn about servers settings and especially neither does my wife.

Please fix this.

[amjjawad  (amjjawad)]

I think this is still happening with Lubuntu 13.10

https://lists.ubuntu.com/archives/lubuntu-users/2014-February/006760.html

If this is a different bug, please advise so that I report new one :)

[Ben Bailess (ben-bailess)]

I am still seeing this bug in 14.04 with gnome-core (minimal gnome). I also get the prompt for admin (sudo) password when the connection/signal is weak, since it might disconnect/reconnect quickly. Instead, that automatic reconnection doesn't happen since I might miss the password prompt and the reconnection never occurs if my PC is unattended.

[David Česal (l-david-y)]

I can confirm this bug in 15.04. We use Ubuntu in standalone terminal which is in sleep at night. When we open it in the morning, it wants to reconnect to wifi network and administator password is required.

[ԜаӀtеr Ⅼарсһуnѕkі (wxl)]

Mathieu, it doesn't seem that the upstream fix in Debian ever got merged into Ubuntu. Is there a reason for this?

[Benoit Grégoire (benoitg)]

Still an issue in Kubuntu 16.04, so apparently it did NOT get merged into Ubuntu.

[buggycub (smusnmr)]

Also an issue in Ubuntu 16.04. I reported it as a bug in
https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1650792
before I detected this thread.

[Mantas Kriaučiūnas (mantas)]

It seems Debian fix is simply to allow users from netdev (and sudo) group add/change system-wide NetworkManager connections, this fix is added in network-manager 0.9.4.0-7 and is merged in Ubuntu,

look at /var/lib/polkit-1/localauthority/10-vendor.d/org.freedesktop.NetworkManager.pkla

[Adding or changing system-wide NetworkManager connections]
Identity=unix-group:netdev;unix-group:sudo
Action=org.freedesktop.NetworkManager.settings.modify.system

So, main problem is that GNOME-Shell users aren't added to netdev group by default?

Walter Lapchynski (wxl) wrote on 2015-06-29: #38
> Mathieu, it doesn't seem that the upstream fix in Debian ever got merged into Ubuntu.
> Is there a reason for this?

[Wendell Nichols (wcn00)]

I just installed kubuntu 18 after a long absence. I found that to make any change to the network settings I had to key in my (16 digit) password multiple times. About 5 times in fact.
Its a laptop. The user has to be able to do things like this.
If I have to modify system files (and reapply those changes after maintenance) then its just not worth it.

[Michel-Ekimia (michel.ekimia)]

Still happening in Ubuntu 20.04 focal , We need to find some workaround for this , any other mobile or desktop OS can do this !

[Alkis Georgopoulos (alkisg)]

My problem is a bit different: everything works fine, but the dialog appears when we ACTIVATE a VPN connection, even if we don't want to modify it.

1) I've prepared a VPN connection for my non-admin users and put it in /etc/NetworkManager/system-connections/vpn.nmconnection.
2) When they click to activate it, they get the "System policy prevents..." dialog.
3a) If I do enter the root password there, the vpn.nmconnection file isn't modified. Why did it ask for permission then?
3b) If the users cancel the dialog (twice), they're able to properly connect to the VPN. Why did it show up then?

That's on fully updated Ubuntu 20.04.4.