|
Bugzilla – Full Text Bug Listing |
| Summary: | PolicyKit asks for root password when activating non-system-wide network | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 12.1 | Reporter: | Rafael Belmonte <EagleScreen> |
| Component: | Basesystem | Assignee: | E-mail List <bnc-team-screening> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Major | ||
| Priority: | P2 - High | CC: | auxsvr, forgotten_Ku1lZ_yaEZ, gp, iceman, ismail, liquidsky42, lnussel, meissner, peter, plinnell, poolbarde, puzel, RBrownCCB, rcornet, rjschwei, roger.luedecke, sledz, stephan.barth, user2304, wstephenson, zoltan.ilyes |
| Version: | Milestone 5 | ||
| Target Milestone: | --- | ||
| Hardware: | i586 | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Rafael Belmonte
2011-09-07 01:50:42 UTC
Hello, same behaviour here. Reproducible: Always Steps to Reproduce: 1.Setup a not system-wide Internet connection via network-manager-kde (wireless). 2.You need to authenticate as root to activate the wireless connection. Expected Results: User connections which are not system-wide connections shouldn’t require the root authentication via PolicyKit-kde. Regards. Same behaviour here, after initial bootup and connection to WLAN a message appears around 5 minutes later saying that Policykit need to be authorised. Enter the root password and the next message to appear is that the WLAN0 has failed with no secrets. Reproducible: Always Dell Studio 1558 with Dell 1397 (BCM4312 based) wifi card I still see this bug in a system upgraded from Milestone 5 to Beta1 (completely upgraded by zypper dup). for instance, it happens when I wake up from suspend to RAM. *** Bug 717159 has been marked as a duplicate of this bug. *** The Bug is still in the Goldmaster. Is there a plan to fix it? In my opinion the settings in /etc/polkit-default-privs.standards are too restrictive, as they prevent a logged in non-root user from creating a personal network connection, which is more strict than we had in 11.4 and earlier. Try adding org.freedesktop.NetworkManager.settings.modify.own yes in /etc/polkit-default-privs.local and run /sbin/set_polkit_default_privs afterward. Okay, works for me. But if I want to remove a connection,I need still a root password. I think too, it's a little bit too strict. This is not a KDE issue. See also https://bugzilla.novell.com/show_bug.cgi?id=728970#c18 I am using echo >>/etc/polkit-default-privs.local org.freedesktop.NetworkManager.settings.modify.system aak:aak:yes I suggest (for laptops at least) org.freedesktop.NetworkManager.network-control auth_admin:auth_admin:yes org.freedesktop.NetworkManager.settings.modify.own auth_admin:auth_admin:yes org.freedesktop.NetworkManager.wifi.share.protected auth_admin:auth_admin:yes org.freedesktop.NetworkManager.wifi.share.open auth_admin:auth_admin:yes org.freedesktop.ModemManager.Device.Control auth_admin:auth_admin:yes The last one allows the user to unlock the modem with a PIN I think Juergen's suggestion goes too far, since that allows all logged in users to modify all users' connections. This behavior is present in both the nm-applet of GNOME and the plasmoid-nm of KDE. I agree with Will. The user should have unrestricted access to personal settings, but not access to setting of other users. If security is a concern, the admin can simply toggle 'ifup' in YaST. This approach to security seems to me to be without any real benefit, and rather introduces potential serious problems. Going back to 11.4 behavior is a sane method, and if further security were needed the admin can audit their own system. I have been digging through documentation on policykit to figure out why NetworkManager needs root for user side settings. I think I may be on to something. It looks like NetworkManager is misidentifying its actions and sending policykit the wrong signal. Here, I have added a local connection and it requires root authentication. Note, that "System Connection" was unchecked and I have had "Connect Automatically" toggled both ways and got the same result. The GNOME network manager also requires root authentication. Notice under "Action" it says,"Modify network connections for all users." However, as the box was unchecked, this is not a correct report of the action. Not sure why Network Manager is listed under Vendor... http://wstaw.org/m/2011/11/21/nm- appletneedsrootimmediatelywhennetworkisselected.png Another attempt in the exact fashion gives a different but similar authentication dialog. Note in this dialog, it correctly identifies the action as "Modify personal network connections." http://wstaw.org/m/2011/11/21/nmneedsrootafterputtinginwifipassword.png A quick look at the policykit module in System Settings shows that the only policy requiring root should be to set system wide connections for all users. No other section here shows a need for authentication. http://wstaw.org/m/2011/11/21/systemnconnectionsonlyoneshowingneedforroot.png Considering what I have figured upon, it would look that the NetworkManager (backend, not desktop specific applet) is misidentifying its actions. However that doesn't explain its asking for root when it does identify the action correctly as user level. There may be multiple issues here, or the KDE module for policykit is misrepresenting the setting actually present. There is no such thing as a "user level" or "personal" network connection. Network connections are *always* system wide. NM 0.9 finally reflects that by storing all connections in /etc. IOW the distinction between "settings.modify.own" and "settings.modify.system" doesn't make sense so both are set to "auth_admin". This setting only affects creating new connections as well as modifying or deleting connections. That is not subject of this bug though. The subject of this bug says "PolicyKit asks for root password when activating non-system-wide network". Ie the 'network-control' setting. That one is set to 'yes' for local users on the active console. IOW if NM asks PK for admin auth when activating a connection the user is either not considered to be on the active console or NM has bugs that make it think it needs to modify connections. The latter could happen for example when an AP goes out of range and NM erroneously assumes the password is wrong because it can't associate. However, since suspend was mentioned I suspect something else. When suspending the system probably switches back and forth between console and X. If nm-applet tries to activate a connection before consolekit notices that the user is on the active console NM may ask PK for auth while a few ticks later it wouldn't do that. To find out whether that is the case add the following line to /etc/polkit-default-privs.local, run set_polkit_default_privs and try to reproduce again: org.freedesktop.NetworkManager.network-control no:no:yes I do not experience any issue when suspending. Only when adding, modifying, or removing a network connection of any scope. I was told recently that the KDE module for PolicyKit is thoroughly broken, which may explain the discrepancy I saw. However, there is still the two screenshots asking for authentication. Each is an identical scenario, but they are giving different reasons for needing authentication. @Ludwig although all connections are stored in /etc, connections may be owned by and limited in scope to individual users by not checking the 'System Connection/Share with all users' checkboxes when creating them. This ownership is indicated by a permissions= line in /etc/NetworkManager/system-connections/<connection>. I don't know the format, I can't find documentation at live.gnome.org/NetworkManager, and I won't UTSL yet. System connections do not have this line, though. settings.modify.own governs the ability to create and modify unshared connections owned by you. settings.modify.system governs shared by all 'system' connections. IOW the implementation of the distinction between personal and system connections has moved from the filesystem and user-specific SettingsService dbus services, to NetworkManager itself, but it still exists and our default polkit policy ignores that. Should I open another bug for this? *** Bug 731561 has been marked as a duplicate of this bug. *** Guys, This is a *not* a good default. Even Linus is rightly complaining: https://bugzilla.novell.com/show_bug.cgi?id=731812 On the topic of 'user' vs 'system' connections While I understand it might be desirable for a user to have a collection of network settings for their use, with a system like NetworkManager controlling the network stack these settings will still have a 'system wide' effect when the user picks their 'personal' settings eg. A fixed IP address will be a fixed IP address for the entire system regardless of whether it is a 'user' or 'system' configuration in NetworkManager that it comes from. Given the unavoidable fact (nature of the beast with a user space network controller) it makes sense that the configuration files are kept in /etc The more relaxed polkit settings may seem counter intuitive and insecure, but I think they are *necessary* for the correct behaviour of NetworkManager (user driven network configuration) The whole point of NetworkManager is to allow a user to do stuff with network configuration we'd normally reserve for root, and right now our standard polkit settings are preventing that. Can we get Wills workaround packaged up and pushed as a maintenance update asap? Looking on an 11.4 system I see a /etc/polkit-default-privs.standard and /etc/polkit-default-privs.restrictive. The .standard file has permissions similar to Will's fix in #c9 that let the user control connections. .restrictive appears to not allow this. This is a best-of-both worlds setup. The default lets users control connections just like the can on other distributions and other OSes, and there's a 'restrictive' set of permissions for those who need extra security. Please restore the 11.4 behaviour in 12.1, changing behaviour of important components like NetworkManager to suit someone's personal security ideology should not be done. This is an autogenerated message for OBS integration: This bug (716291) was mentioned in https://build.opensuse.org/request/show/93202 12.1 / polkit-default-privs This is an autogenerated message for OBS integration: This bug (716291) was mentioned in https://build.opensuse.org/request/show/93203 12.1 / polkit-default-privs I tried the on click installation provided by the above OBS link. Works fine on my system -feeling is like the old from opensuse 11.4. Hope this patch will come via the official updates soon... (In reply to comment #9) > I suggest (for laptops at least) > > org.freedesktop.NetworkManager.network-control > auth_admin:auth_admin:yes > org.freedesktop.NetworkManager.settings.modify.own > auth_admin:auth_admin:yes > org.freedesktop.NetworkManager.wifi.share.protected > auth_admin:auth_admin:yes > org.freedesktop.NetworkManager.wifi.share.open > auth_admin:auth_admin:yes > org.freedesktop.ModemManager.Device.Control > auth_admin:auth_admin:yes This gives errors on running: set_polkit_default_privs afterward > The last one allows the user to unlock the modem with a PIN > > I think Juergen's suggestion goes too far, since that allows all logged in > users to modify all users' connections. I think it should be this no? org.freedesktop.NetworkManager.network-control yes org.freedesktop.NetworkManager.settings.modify.own yes org.freedesktop.NetworkManager.wifi.share.protected yes org.freedesktop.NetworkManager.wifi.share.open yes org.freedesktop.ModemManager.Device.Control yes This is an autogenerated message for OBS integration: This bug (716291) was mentioned in https://build.opensuse.org/request/show/94704 Factory / polkit-default-privs Can we espect some kind of patch on the future, perhaps mid january? Its a shame that Opensuse has decayed this way since 11.4, with the 11.5 tag we could forgive a little more.. Just upping versions numbers does not solve anything actually already released |