In the initscript for OpenVPN the user privileges are dropped to the "openvpn" user if it is determined that the config is not a client and a user/group was not specified in the config file. However, if DETECT_CLIENT is set to no in the conf.d/openvpn file, the current initscript enables the user privilege downgrade anyway without first checking if the config looks like a server. The patch below adds logic to the privilege downgrade to verify that the config looks like a server and adds a test so the privilege downgrade can be overridden through the conf.d/openvpn file. While the override isn't strictly necessary, I think it may be useful for sites that wish to disable privilege downgrading completely without having to specify a user/group of root in all config files.
Created attachment 153391 [details, diff] droppriv-config improvement patch A patch for the files/ subdirectory of the ebuild as explained above
See bug#181000 If you are not in a client configuration, there is no need to have openvpn running with root privilege. So I don't think the patch is usefull and if you really want to have root user, you can put it in the configuration file.
Thanks for the reference bug. You correctly point out (as I did above), a user and group of root can be specified in the OpenVPN config files if really required. In some instances where I use OpenVPN under Gentoo, a mixture of both client and server configurations run at the same time. In these cases having the master OpenVPN script (which all others are symlinked to) decide that when DETECT_CLIENT is set to no that the privilege downgrade will occur anyway is a behavior that I don't want or expect. This means that even client configurations end up having permissions downgraded to the openvpn user, causing the Gentoo up/down scripts to fail. The patch I've proposed will keep the current behavior as a default, but provides an important test for people that do choose to disable the client detection through the DETECT_CLIENT variable. As I mentioned in Comment #1, the addition of the DROPPRIV_SERVER variable could be omitted if it doesn't seem as useful, but having the 'else' statement alone on line 104 of the current initscript is indeed a bug reproducible by enabling DETECT_CLIENT in conf.d/openvpn and starting a client instance. Are people who use these combination of settings supposed to set the root user/group as well as call the Gentoo-specific up/down scripts in all client configurations?
In follow-up to Comment #3, it seems this isn't actually an issue since any initscripts that are symlinked to the master openvpn script don't source the /etc/conf.d/openvpn file (which I assumed they did like the net.* scripts.) This means that users wishing to disable DETECT_CLIENT for a particular configuration won't suffer from this problem when calling other initscripts; other symlinked initscripts source the symlinked name from conf.d/ instead, allowing DETECT_CLIENT to be set to yes as a default.
And for me, it is a good behavior to drop the privilege of such services by default if the user didn't specify something.
