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
/[email protected] 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 :-)
** Bug watch added: Debian Bug tracker #866523
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866523
** Bug watch added: community.openvpn.net/openvpn/ #918
https://community.openvpn.net/openvpn/ticket/918
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1787208
Title:
Openvpn routing issue
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openvpn/+bug/1787208/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
