Hide Forgot
Description of problem: The default permissions on the directory /etc/openvpn/server block the correct functioning of the client-config-dir directive in the server's vpn configuration file Version-Release number of selected component (if applicable): openvpn-2.4.4-1.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1. Copy the sample config file /usr/share/doc/openvpn-2.4.4/sample/sample-config-files/server.conf to appropriately-named file in /etc/openvpn/server 2. Set server name, keys, etc. in the file created in step #1 as appropriate for your environment. 3. Start the openvpn server 4. Configure a client (on a different machine) to connect to this server and versify that it is able to connect. 5. Stop the openvpn client and server. 6. On the server, edit the server config file to uncomment the line: ;client-config-dir ccd 7. Create a directory /etc/openvpn/server/ccd 8. Create a file in /etc/openvpn/server/ccd that matches the name of the client configured in step #4 and place a directive in this file that overrides the default configuration. (e.g. ifconfig-push 10.9.0.42 255.255.255.0) but could work in your environment. 9. Start the openvpn server and client. Actual results: The configuration specified in step #8 is not applied. Expected results: The configuration specified in step #8 is applied. Additional info: The group ownership of /etc/openvpn/server needs to be changed to openvpn so that the openvpn server process can read the contents of /etc/openvpn/server/ccd after it has dropped root permissions.
Confirmed, this is wrong. Group owner should be openvpn. Will fix this in the next update.
openvpn-2.4.5-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-cf6336da5c
openvpn-2.4.5-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2018-58cc91a549
openvpn-2.4.5-1.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-57e2736a0c
openvpn-2.4.5-1.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-58cc91a549
openvpn-2.4.5-1.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-cf6336da5c
openvpn-2.4.5-1.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-57e2736a0c
openvpn-2.4.5-1.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.
openvpn-2.4.5-1.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
openvpn-2.4.5-1.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.
This problem is still present in 2.4.6-1.el7 - /etc/openvpn/server does not have g+r and o+x after the update.
(In reply to zanu from comment #11) > This problem is still present in 2.4.6-1.el7 - /etc/openvpn/server does not > have g+r and o+x after the update. Really? Well, o+x was never the intention, so that is correct. But it should be g+rx with openvpn being the owner. Whcich can be easily verified: $ yumdownloader openvpn openvpn-2.4.6-1.el7.x86_64.rpm $ less openvpn-2.4.6-1.el7.x86_64.rpm | grep etc/openvpn - Fix wrong group owner of /etc/openvpn/{client,server} (rhbz#1526743) drwxr-xr-x 2 root root 0 Apr 26 17:04 /etc/openvpn drwxr-x--- 2 root openvpn 0 Apr 26 17:04 /etc/openvpn/client drwxr-x--- 2 root openvpn 0 Apr 26 17:04 /etc/openvpn/server $ Since all these directories are tagged as %config, it might be it won't override existing installs.
Requiring o+x was my mistake, apologies. The (commented) "user" and "group" directives in /usr/share/doc/openvpn-2.4.4/sample/sample-config-files/server.conf suggest to use "nobody". So naturally, when uncommenting those directives, OpenVPN failed to read the client-config-dir after each update, before _and_ after this bug was fixed.
Ahh, I see. Those sample config files have mostly been untouched since at least 2005 and the RPM packaged sample configs are just taking whatever the upstream community provides. There's just been a few minor changes 3-4 times since that time, mostly just enhancing the basic security. That said, the upstream expectation of these files is not to provide something which works out-of-the-box, but more to provide a template of things you would want to consider to include and some options which are mandatory. These sample configs needs to be adopted to the local system. The nobody user/group notion is thus mostly historical. In the early days before OpenVPN got widely deployed, it was not uncommon to run most daemons as nobody. But in this time and era that is not considered too clever. An apache process running as nobody and an openvpn process running as nobody can in most cases read each others files. That said, many Linux distributions don't create the openpvn user/group (like Debian/Ubuntu, iirc); but Fedora and RHEL/CentOS does. I'll consider improving this with the upstream community.