Re: NetworkManager permissions
Hi Dan, Thank you for the reply! This sounds like a good solution to me, unfortunately we are indeed using Gnome Shell UI so that would cause a problem. So what you are saying is that right now there is no way to achieve this while using gnome shell ? On Wed, Dec 17, 2014 at 4:53 PM, Dan Williams d...@redhat.com wrote: On Thu, 2014-11-27 at 11:59 +0100, Peter Magnusson wrote: Im having some problems with permissions on NetworkManager. We are in the process of migrating our clients from RHEL 6.6 to RHEL 7. The clients connect to our wireless network using eap-tls, we provide the configuration,certificate and keys for this from our central configurationserver so that the connection is transparent to the user. In RHEL6.6 the password for the privatekey(pkcs12 used for authentication) was not visible to the users only to administrators. This was achieved by setting the connection as system wide in which case the configfile was stored under /etc/sysconfig/network-scripts and only accessible by root. In RHEL7 and NM version 0.9.9.1-28.git20140326.4dba720.el7_0.2 (lbuild from git) we can still limit the permissions to NM config using polkit but when doing this we also limit the possiblity for the user to add new wifi-networks. So what i would like to achieve is to limit access to existing connections (or connections not added by user) but i still want the users to be able to add new wificonnections. Is this possible ? I looked into this yesterday, and I think the way forward here is to restrict the user's permissions for modify.system, but allow them permissions for modify.own (own == self, not possession). This will prevent the user from being able to change any connection that is in /etc and does not have specific permissions. But it allows the user to create new connections that are restricted to that user only. There's one catch though; if you're using the GNOME Shell UI on RHEL 7.0 it doesn't set the necessary flags to create these user-specific connections when the modify.system permission is denied. We can work on fixing that though. Do you think this solution would work for you? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Notification disjoint - VPN now failed, notifications showing still connected.
Dan I've responded with a couple of log attachment zips direct to your account, if you don't see them they may be in your spamtrap. Regards Tony On 17 December 2014 at 15:56, Dan Williams d...@redhat.com wrote: On Wed, 2014-12-17 at 14:45 +, Another Sillyname wrote: I have setup a VPN on a Laptop using Fedora 21 x86_64. The VPN works fine however the gnome notifications are not reflecting the true state of the VPN. In Network Settings you can connect to XXXVPN using the ON/OFF switch. If you then do a 'nmcli connections show --active' you will get the correct information regarding the VPN and also the tun will show active on a separate line. ifconfig reports the 'hard' settings for the nic together with the relevant VPN settings. I had noticed on a couple of occasions the VPN had dropped however the gnome settings were still showing active. So if the VPN gets dropped (NOT manually disconnected) Gnome settings will still show the VPN as connected. nmcli connections show --active will still show the VPN as active, however the 'tun' line has now disappeared confirming the VPN is down. If this happens, then it seems that the VPN you're using isn't notifying the NM VPN plugin about the failure, or there's a bug in the plugin. But we'll need some logs for that. Based on what you describe, I think this VPN drop thing is a bug in NM or the VPN plugin. Can you grab some /var/log/messages about that? Also very useful is to run the specific VPN plugin with --debug --persist which will dump a ton of information that we can use to figure it out. eg: /usr/libexec/nm-vpnc-service --debug --persist /usr/libexec/nm-openvpn-service --debug --persist Dan ifconfig shows the 'hard' settings for the nic but no entry for the VPN. This means there's a disjoint in what is being reported via Gnome/NetworkManager and the actuality of the status of the VPN. In effect there would appear to be a need to 'actively poll' the tun to ensure the VPN is still active and if the tun fails NetworkManager needs to be updated accordingly. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager permissions
On Thu, 2014-12-18 at 11:44 +0100, Peter Magnusson wrote: Hi Dan, Thank you for the reply! This sounds like a good solution to me, unfortunately we are indeed using Gnome Shell UI so that would cause a problem. So what you are saying is that right now there is no way to achieve this while using gnome shell ? There might be something we can do in NM itself though, given the way the shell and most other clients create new connections. But either way, best thing to do would be to file a bug at http://bugzilla.redhat.com against RHEL7 and assign to the NetworkManager component so it doesn't get lost. Does that sound OK? Thanks! Dan On Wed, Dec 17, 2014 at 4:53 PM, Dan Williams d...@redhat.com wrote: On Thu, 2014-11-27 at 11:59 +0100, Peter Magnusson wrote: Im having some problems with permissions on NetworkManager. We are in the process of migrating our clients from RHEL 6.6 to RHEL 7. The clients connect to our wireless network using eap-tls, we provide the configuration,certificate and keys for this from our central configurationserver so that the connection is transparent to the user. In RHEL6.6 the password for the privatekey(pkcs12 used for authentication) was not visible to the users only to administrators. This was achieved by setting the connection as system wide in which case the configfile was stored under /etc/sysconfig/network-scripts and only accessible by root. In RHEL7 and NM version 0.9.9.1-28.git20140326.4dba720.el7_0.2 (lbuild from git) we can still limit the permissions to NM config using polkit but when doing this we also limit the possiblity for the user to add new wifi-networks. So what i would like to achieve is to limit access to existing connections (or connections not added by user) but i still want the users to be able to add new wificonnections. Is this possible ? I looked into this yesterday, and I think the way forward here is to restrict the user's permissions for modify.system, but allow them permissions for modify.own (own == self, not possession). This will prevent the user from being able to change any connection that is in /etc and does not have specific permissions. But it allows the user to create new connections that are restricted to that user only. There's one catch though; if you're using the GNOME Shell UI on RHEL 7.0 it doesn't set the necessary flags to create these user-specific connections when the modify.system permission is denied. We can work on fixing that though. Do you think this solution would work for you? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: The short road to 1.0 (ANN: 0.995 released)
On Wed, 17 Dec 2014 09:56:59 -0600 Dan Williams d...@redhat.com wrote: On Fri, 2014-12-12 at 16:05 -0600, Dan Williams wrote: Hi everyone! The 1.0 release is imminent. We've been cleaning out the 1.0 tracker bug [1] for more than a month. With your help we'll get there next week! A holiday present for everyone! We're getting very close to 1.0, so this is last call for any showstopper bugs that you can find. Thanks! It's all working well here, best I can tell. -RW ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: The short road to 1.0 (ANN: 0.995 released)
On Thu, 2014-12-18 at 11:15 -0600, Robby Workman wrote: On Wed, 17 Dec 2014 09:56:59 -0600 Dan Williams d...@redhat.com wrote: On Fri, 2014-12-12 at 16:05 -0600, Dan Williams wrote: Hi everyone! The 1.0 release is imminent. We've been cleaning out the 1.0 tracker bug [1] for more than a month. With your help we'll get there next week! A holiday present for everyone! We're getting very close to 1.0, so this is last call for any showstopper bugs that you can find. Thanks! It's all working well here, best I can tell. Awesome, thanks for the feedback. We found one issue with external software devices last night, but that's now been fixed and I think 1.0 is good to go. Absolute last call now :) Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [systemd-devel] Cycle between logind and NetworkManager in case of remote user database
В Mon, 15 Dec 2014 14:20:45 -0600 Dan Williams d...@redhat.com пишет: On Mon, 2014-12-15 at 20:40 +0300, Andrei Borzenkov wrote: В Mon, 15 Dec 2014 11:34:17 -0600 Dan Williams d...@redhat.com пишет: On Mon, 2014-12-15 at 16:11 +0100, Lennart Poettering wrote: On Sat, 13.12.14 10:09, Andrei Borzenkov (arvidj...@gmail.com) wrote: NetworkManager sets logind inhibitor lock to monitor for suspend events. So it implicitly requires logind to be present when NM starts. NM doesn't actually require that, it just wants to know about the signals that logind sends and have a chance to respond to them. If logind isn't running, NM shouldn't really care. But perhaps expectation is not matching reality in the code. Any idea what it needs the inhibitor for? To be aware of suspend/resume events of course. NM may want to disconnect the network cleanly before suspending, and on resume may need to clean up network connections and restart certain operations. logind is ordered after nss-user-lookup.target. If we have remote user database, it means that logind depends on network to be up and running. If network is provided by NetworkManager we have a loop. Due to the fact that NetworkManager service itself does not declare dependency on logind, it can be pretty hard to recognize. Any idea how it can be solved nicely? I can only think of delaying inhibitor logic in NM until logind is started. Not sure what side effects it may have. Yeah, I figure if they want to be able to run in early parts of boot they should watch logind's bus name and create their inhibitor only after it appears. Does logind get D-Bus autolaunched? Yes. NM is just creating a bus proxy for the logind DBus service, and then attempting to call a D-Bus method on logind to take an inhibitor. It doesn't actually care that much about the result, but NM doesn't pass G_DBUS_CALL_FLAGS_NO_AUTO_START to prohibit logind from launching. Perhaps NM is requesting logind to start through D-Bus autolaunch, but since the network isn't up yet logind then fails itself? systemd tries to launch logind service which now waits for services it is ordered After and eventually times out. NM patch filed for review by NM dev team: https://bugzilla.gnome.org/show_bug.cgi?id=741572 Yes it was reported to fix the problems during system startup. Thank you! I wonder if there is any way to delay suspend in race free way. Also, I don't think logind should fail if there is no network; Logind was not even started - systemd waited for required services to start it and timed out. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
