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

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

Attachment: pgplReBfpdAEd.pgp
Description: PGP signature

Reply via email to