On 29-11-2016 17:00, Giancarlo Razzolini wrote:

Em novembro 29, 2016 14:38 Christian Hesse escreveu:

...

We need root privileges at initialization phase, no? Privileges are dropped to nobody/nobody when initialization sequence completed.

If we can make things work with non-root system user... Let me know how to do that. :D

We just need root for creating the tun devices and destroying them. I managed to make an entire unprivileged deployment.

Basically all I need is this:

[Service] User=openvpn Group=openvpn PermissionsStartOnly=true ExecStartPre=-/usr/bin/openvpn --rmtun --dev tun0 ExecStartPre=/usr/bin/openvpn --mktun --dev tun0 --dev-type tun --user openvpn --group openvpn ExecStart= ExecStart=/usr/bin/openvpn --cd /etc/openvpn --config %i.conf --daemon openvpn@%i --writepid /run/openvpn/openvpn@%i.pid --status-version 2 PIDFile=/run/openvpn/openvpn@%i.pid

I see a problem with this, the configuration file is not hard coded (good) but the tun device is hardcoded (bad). What happens if one wants more than one server or client instances? What if the user wants to use tap instead of tun devices? It will also not respect the naming configured in the configuration file, or at least it will have to match tun0. Trying to ship more secure unit files/configuration is good but it seems this would probably be best described in the wiki and let the user implement it if desired.

The config file doesn't need any actual user/group configuration, because it is already started with the right user/group. It needs to use a different iproute binary (which in my case is a script) that has sudo permissions for the openvpn user to run the ip command as root.

...

The new systemd units create this automatically. (Well, actually /run/openvpn-client and /run/openvpn-server.)

Nice to hear this.

...

Just followed the link from our wiki [2]. Probably you can make this work, but I am not convinced this can be packaged to work smoothly. Dynamic device naming, up/route-up/... scripts, ... There is lot of stuff that can and will break.

Still, if you have some clues on how to package this...

I never meant for you (us) to package such setup. I was just making the case for a dedicated openvpn system user and it's run directories. At least one of those is already taken care of. If we can deploy such unprivileged systemd units, alongside upstream official ones, it's another matter.

Personally I'm okay with all of this and I'll accommodate my setup, no matter how openvpn gets packaged. I had to compile openvpn for at least two release cycles because of a bug on it[0]. I think you'll probably remember that one.

Cheers, Giancarlo Razzolini

[0] https://bugs.archlinux.org/task/50090

-- Mauro Santos