Comment 5 for bug 1586570

Revision history for this message
Brett Keller (blkeller) wrote :

I encountered this same problem on Ubuntu MATE 16.04.2.

Every time the OpenVPN connection attempted to automatically restart itself, it was unable to do so. This breaks the connection until a manual restart of the connection through the NetworkManager GUI.

This bug is easily reproducible by sending the openvpn process a signal to restart itself:
 $ sudo killall -SIGUSR1 openvpn
Watching syslog and using strace on the process show it is unable to properly restart because of lack of privileges and being jailed in the chroot environment.

As others have mentioned here, I tried adding more and more dependencies into the chroot, but after a while it just got ridiculous, unmaintainable, and never actually fixed the problem.

*The following workaround does fix the problem for me.*

NetworkManager attempts to run openvpn as an unprivileged user and in a chroot. Normally, this is a good security practice, but the implementation unfortunately is half-baked. The openvpn man page calls out several problematic cases in which dropping privileges or chrooting can cause failures on connection restarts, and both the man page and official how-to seem lukewarm at best on the added security benefits. The benefits are even less clear for a client-only configuration as opposed to a server. A reasoned cost/benefit analysis for my own use-case shows the costs of dropping privileges and/or chrooting when running openvpn outweigh the benefits, at least at this point in time (02/2017).

While disabling NetworkManager and running openvpn manually or as a standalone service is a valid solution for running openvpn as root, there are other benefits to running NetworkManager on a desktop or laptop system that I don't want to give up. However, getting NetworkManager to play nice is not trivial. As of late Sep. 2016, NetworkManager changed their default behavior with regard to openvpn, forcing it to always run with least privileges:
https://github.com/GNOME/network-manager-openvpn/commit/03fc318608b0d60decaced38e0de7a74c2ac5c4c

As mentioned in the source code, the only way to override this default is by setting a few environment variables with null values. The cleanest way to do this is to create a drop-in systemd configuration file for NetworkManager:
1. Create the directory to hold the drop-in configuration file:
 $ cd /etc/systemd/system
 $ sudo mkdir NetworkManager.service.d
 $ cd NetworkManager.service.d
2. Create a new conf file:
 $ sudo nano disable-openvpn-reduced-privileges.conf
3. Add the following content to the file:
 # Disable NetworkManager's OpenVPN plug-in from performing chroot and dropping privileges by default (null assignment)
 [Service]
 Environment="NM_OPENVPN_CHROOT="
 Environment="NM_OPENVPN_USER="
 Environment="NM_OPENVPN_GROUP="
4. Save the file and exit nano
5. In order for the changes to take effect, you may either restart the NetworkManager service and quit & restart your openvpn connection, or if it is simpler for you, just restart your computer.

You can test if this is working properly several ways:
1. Systemd should show that the drop-in configuration is in use:
 $ systemctl status NetworkManager
  NetworkManager.service - Network Manager
  Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled; vendor preset: enabled)
  Drop-In: /etc/systemd/system/NetworkManager.service.d
     +-disable-openvpn-reduced-privileges.conf
2. When openvpn is running it should be running as the root user. This can be verified using ps or any other process lister/monitor.
3. Force a running openvpn connection to restart and see if it is successful:
 $ sudo killall -SIGUSR1 openvpn