jonathanio / update-systemd-resolved

Helper script for OpenVPN to directly update the DNS settings of a link through systemd-resolved via DBus.
Other
761 stars 94 forks source link

logger --id fails with "Operation not permitted" #25

Closed dermarens closed 7 years ago

dermarens commented 7 years ago

Hey there! First let me say thanks a lot for this useful script.

I just found a minor issue while following systemlogs with journalctl -fe

Mar 31 20:21:01 karotte openvpn[6961]: /etc/openvpn/update-systemd-resolved tun0 1500 1556 some.company.ip.v4 255.255.255.0 init
Mar 31 20:21:01 karotte openvpn[6961]: + logger -s --id=6971 -t update-systemd-resolved -p user.info -- 'Link '\''tun0'\'' coming up'
Mar 31 20:21:01 karotte openvpn[6961]: logger: send message failed: Operation not permitted
Mar 31 20:21:01 karotte openvpn[6961]: <14>Mar 31 20:21:01 update-systemd-resolved[6971]: Link 'tun0' coming up

i used "set -x" to get some more debugging infos during the logger run.

While this fails when executed from within update-systemd-resolved i works when executed from the commandline

Console:

i|karotte ~ # logger -s --id=6971 -t update-systemd-resolved -p user.info -- 'Link '\''tun0'\'' coming up'
<14>Mar 31 20:31:40 update-systemd-resolved[6971]: Link 'tun0' coming up

Journal:

Mar 31 20:31:40 karotte update-systemd-resolved[7075]: Link 'tun0' coming up

Changing the script like shown below gets rid of the error

diff --git a/update-systemd-resolved b/update-systemd-resolved
index 422d105..db2cc13 100755
--- a/update-systemd-resolved
+++ b/update-systemd-resolved
@@ -32,7 +32,7 @@ DBUS_NODE="/org/freedesktop/resolve1"
 SCRIPT_NAME="${BASH_SOURCE[0]##*/}"

 log() {
-  logger -s --id="$$" -t "$SCRIPT_NAME" "$@"
+  logger -s -t "$SCRIPT_NAME" "$@"
 }

This happens using systemd-233-r1 on gentoo linux

Any ideas what might be going on here?

jonathanio commented 7 years ago

I've not noticed this before, but I wonder if by trying to use the PID of the parent process to log against is not permitted in some situations when privileges have been dropped under systemd.

Looks like the --id option may need to be removed from the script.

terminalmage commented 7 years ago

I can confirm that removing the --id arg from the log function fixes this. Without removing it, the script fails and the nameserver entries are not added.

guruxu commented 7 years ago

+1 at least debian doesn't like --id to have a value

benvh commented 7 years ago

+1 arch also does not like --id