GNOME Bugzilla – Bug 760917
[patch] Add option to load configuration file
Last modified: 2016-03-11 18:28:31 UTC
Created attachment 319475 [details] [review] Patch Good morning, this patch adds possibility to use OpenVPN config file. To avoid users setting arbitrary files with possible harmful configuration, the specified file must be within /etc directory. When config file is used, most of the other options are deactivated. This patch does not touch anything around user interface. To test this feature, create a OpenVPN connection available to all users, then edit appropriate file in /etc/NetworkManager/system-connections to add this option: [vpn] config=/etc/...your-config-file I'm not sure where is configuration validated, so I didn't change it. It should be updated so if `config` option is set, nothing else is required. User interface should be updated in a similar way, greying out everything else when config file is specified.
There were numerous requests like this in the past and got rejected. I don't think we want to do this, because - NetworkManager needs to understand the way it invokes openvpn. By specifying an opaque configuration file, openvpn might behave in an unexpected way. Which is especially bad because our way how to report failures to connect to the UI is pretty limited. - security considerations. A regular user cannot be allowed to inject a config-file to openvpn, and requiring the configuration file to be owned by root makes the option only useful for root users. We need to teach NM's openvpn pluing every single option it should understand. What we however could do is to allow configuring a openvpn config file and the plugin would import it first and then use the imported setting. I think that could be useful so that you have one configuration file that can be both used by openvpn service and nm-openvpn-plugin.
I see two scenarios here: 1. Regular desktop user 2. Root user with some unusual setup I completely agree with you when it is about the regular user. Allowing regular user to inject an arbitrary config file to openvpn is a big security hole. In this case the import tool is a good idea. Also a lot of VPN servers provide a config file, so user is expected to give it to OpenVPN client instead of configuring everything manualy. However, the second scenario is very different. There are multiple reasons why it is useful to use custom config file without any processing. First, there will always be a gap between latest version of OpenVPN and Network Manager OpenVPN plugin and Network Manager user interface. Every new option in OpenVPN must make it to NM plugin and then to NM GUI (like KDE5 plasmoid, which is not part of NM). It takes a while (months at least). Second reason is when user have some unusual setup and wants NM only to turn VPN on and off (I've seen such bug report). Such user is skilled enough to read logs and update config files, so he does not need GUI for everything. When NM says 'Error', he will know what to do. Third reason is that some options simply may not be supported by Network Manager, because they cause troubles and/or they are security risks. Like calling a post-up hook. Some other option may simply be too rarely used and too hard to implement (I've seen that reply in other bugreports). Easy solution to all these problems is to teach Network Manager how to get out of the way. There should be a big warning in documentation saying it may not work and use on your own risk.
The import/export code of the VPN plugin is already used by nm-applet and gnome-control-center. Since version 1.2 is also used by nmcli and could potentially/hopefully be leveraged also by nm-plasma, python, etc. Thus, optimistically the scope of the import/export code will grow, giving more incentive to extend and improve it. Adding a --config option makes it less attractive to do so and everybody would settle on the (flawed) workaround. I personally think it'd be wrong to do so. But well... just an opinion.
Agreed with Thomas. With OpenVPN's number of options it's really a pain in the ass to support each single one and we can't just allow the user to use arbitrary ones without consuderation due to the possible security implications (and interaction with the GUI tools). I really wish they had sane negotiation and the VPN server oprators did saner setups, but sadly there's not much we can do about it. What we can do add support for options that are known useful. Closing this; please feel free to reopen if there's particular options you'd like to add support for.