If you are sure the permissions are correct on the directory, I'm guessing this is related to SELinux - especially if you are starting the daemon via the 'service' command or /etc/init.d script.
You can check the status by running the command 'getenforce', If that returns 'Enforcing', you most likely have SELinux issues. If it returns 'Permissive' or 'Disabled', it is something else.
If SELinux is set to 'Enforcing', try temporarily to switch to 'Permissive' by doing 'setenforce 0'. Verify with 'getenforce' that it is not 'Enforcing'. Try now to run OpenVPN and see how it behaves. If it now works, you know for sure it is SELinux which denies this access. I suggest that you do not consider running in 'Permissive' or disable SELinux as a solution. Rather try to let SELinux allow OpenVPN to write these files. So do a 'setenforce 1' now, to move back to 'Enforcing'.
I'd suggest you to use /var/lib/openvpn for this stuff. Give the --user and --group you define in the config also the ownership of this directory. Then the tricky part. OpenVPN runs in a SELinux domain called openvpn_t. This domain should have read/write access to files with a SELinux type called openvpn_tmp_t. This should be used by OpenVPN for such stuff. To check if this is the right solution, do this:
Code: Select all
[root@host: ~] mkdir -m 770 -p /var/lib/openvpn
[root@host: ~] chown openvpn:openvpn /var/lib/openvpn
[root@host: ~] chcon -t openvpn_tmp_t /var/lib/openvpn
Now modify your config file to use /var/lib/openvpn for these temp files and see how it works. If this solves it, then you should write a little OpenVPN SELinux module so that the /var/lib/openvpn directory keeps the proper SELinux context, even when the filesystem is relabelled (using the 'restorecon' command).
Update: Please note that this is very Fedora/RHEL/CentOS specific. The security context of OpenVPN runs under and which SELinux types are available may differ in other distributions.
