[arch-general] [arch-dev-public] Preparing OpenVPN 2.4.x - possible incompatible changes

[Mauro Santos]

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