Comment 31 for bug 1787208

I focused a bit on learn-address.
It behaves quite normal.

There were more tests involved, but I always went back and try to find the minimal changes.

- without sudo setup I see "openvpn : user NOT in sudoers" (as expected)
# Change: add sudo to openvpn
- with sudo I get
  - sudo: unable to send audit message
  - sudo: /etc/openvpn/scripts/test.sh: command not found
# Change: make sure the scripts are +x (I verified that CAP_DAC_READ_SEARCH was not needed to avoid this)
  - sudo: unable to send audit message
  - sudo[6345]: PAM audit_log_acct_message() failed: Operation not permitted
  - sudo[6345]: pam_unix(sudo:session): session opened for user root by (uid=0)
  - sudo[6345]: openvpn : pam_open_session: System error ; TTY=unknown ; PWD=/etc/openvpn ;
       USER=root ; COMMAND=/etc/openvpn/scripts/test.sh add 10.8.0.2 guest1
  - sudo: pam_open_session: System error
  - sudo: policy plugin failed session initialization
# Change: add CAP_AUDIT_WRITE
  - as before (even the audit messages stayed as is)
# Change: CAP_DAC_READ_SEARCH
  - as before
# Change: Drop all Bounding set (=~ to have no bounds)
  - as before
# Change ProtectSystem=false
  - as before

Now that we are here that brings us to this being more of a re-occuring thins than I thought.
See: https://bugs.launchpad.net/ubuntu/+source/openvpn/+bug/1511524
And related: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866523
Which lead to: https://community.openvpn.net/openvpn/ticket/918

But as of my tests atm, adding CAP_AUDIT_WRITE ?no more? is enough to get it to work these days.
Also Upstream hasn't changed anything for ticket 918.
Upstream did take it into This repo though: https://github.com/OpenVPN/sbuild_wrapper/tree/master/packaging/xenial/debian

Which is a copy of that times Ubuntu/Debian packaging.

Now by using what upstream provides in the main repo we differ in our systemd unit, and upstream packaging not their own ./distro/systemd/openvpn-server@.service.in into their .deb but instead a different service makes it work (at least for your case here with "CAP_DAC_READ_SEARCH CAP_AUDIT_WRITE".

But neither of these avoids the pam/audit errors that we see.
IMHO we will need to:
- identify a path to get sudo working again in these cases
- once known need to decide if that can be a default ocnfig or needs to be an admins choice
- check how much of CAP_DAC_READ_SEARCH CAP_AUDIT_WRITE or similar we need
- wake up the upstream bug on this and provide a PR to include the rules that they include in their own .dbe
- Adapt Ubuntu and Debian to do so as well.

If time permits I'll try more configs, but I can't make any promises.
This becomes more interesting, but also seems harder to solve the longer I look at it :-)