Not working on macOS 10.15.5

[florianfink]

Updated to 10.15.5 today. Since then, the bitbar plugin (latest version) only shows the exclamation mark and is not able to switch to dnscrypt. The dnscrypt-proxy service is up to date and running. I'm not sure how to debug this, would appreciate help :)

When changing the DNS manually to 127.0.0.1, everything works as expected and the bitbar plugin also shows the lock emoji. So the issue seems to be switching the DNS settings.

[cboone]

I'm seeing the same thing. I wonder if it's some permissions / access control change?

I've also tried using @JayBrown's https://github.com/JayBrown/DNSCrypt-Menu and it appears to be having the same problem.

[cboone]

Both of them use the same mechanism for actually doing the DNS server update:

if [ "$#" -gt 0 ]; then
	wanted_resolvers="$*"
	# shellcheck disable=2086
	networksetup -setdnsservers "$service" $wanted_resolvers
	flush_dns_cache 2>/dev/null
	exit 0
fi

[JayBrown]

I haven't visited the DNSCrypt-Menu for a very long time, and I don't know when I'll get around to it… if at all… because I'm thinking about running a local DNS with unbound eventually, and dnscrypt only integrated as a forward resolver.

[cboone]

Looks like networksetup behavior now depends on the type of user running it:

networksetup Command
Starting with macOS 10.15.5, the networksetup command behaves differently when run as a standard user versus an admin user. Standard users can do the following:
• 1. Read various network settings
• 2. Turn Wi-Fi power on or off (networksetup -setairportpower en0 on)
• 3. Change the Wi-Fi access point (networksetup -setairportnetwork en0
ExampleWiFiAP)
Other network settings can no longer be modified by standard users via networksetup.
For admin users, networksetup will continue to behave as it has in previous releases of macOS, provided System Preferences > Security & Privacy > Advanced… > “Require an administrator password to access system-wide preferences” is unchecked (which is the default state). If it is checked, admins will be bound by the same constraints as standard users when
using networksetup.

https://mrmacintosh.com/whats-new-in-the-macos-catalina-10-15-5-update-19f96/

[cboone]

Got it, thanks @JayBrown.

[JayBrown]

"Require an admin pw to access system-wide prefs" should imho be enabled for security reasons. It is on my system.

So it seems that switchers for dnscrypt-proxy would need a privileged helper, just to be on the safe side. But afaik you can't have a privileged helper for shell scripts. The only workaround I can think of is that the non-privileged script writes a file with instructions to a specific directory, and that directory is constantly being watched by a privileged LaunchDaemon (with the WatchPaths key), which then reads the newly created file & runs its own privileged script according to the instructions coming from the non-privileged script, e.g. changing DNS settings etc.

[jedisct1]

Oh, no :(

[cboone]

Okay, I got mine working, but it's not an ideal solution. I prepended sudo onto:

bitbar-dnscrypt-proxy-switcher/dnscrypt-proxy-switcher.10s.sh

Line 166 in a7a15a2

networksetup -setdnsservers "$service" $wanted_resolvers

And added an entry like this to my sudoers file (using visudo):

my_non_admin_username ALL = (root) NOPASSWD: /usr/sbin/networksetup

(More info on the latter in this SO answer.)

I'm not sure how to fix this in a more general way, or without requiring sudoers editing. If anyone has thoughts, I can throw a PR together.

[ruffian]

maybe we can run networksetup with admin rights prompt like this in a commandline

osascript -e 'do shell script "networksetup -setdnsservers Wi-Fi 127.0.0.1" with administrator privileges'

[cboone]

Yeah, that seems to work, albeit with a requirement to enter your password every time, which is suboptimal.

Put:

osascript -e "do shell script \"networksetup -setdnsservers $service $wanted_resolvers\" with administrator privileges"

In place of:

bitbar-dnscrypt-proxy-switcher/dnscrypt-proxy-switcher.10s.sh

Line 166 in a7a15a2

networksetup -setdnsservers "$service" $wanted_resolvers

[jedisct1]

Instead of installing a LaunchDeamon (nobody likes these), maybe requesting administrator privileges can be used to spawn the script that watches for changes, as suggested by @JayBrown

The password would be asked only once

[JayBrown]

I just learned from another source that you can apparently run "do shell script" plus "with administrator privileges" with an in-AppleScript password argument to circumvent a password prompt. So you could also (at first run) ask the user to enter his admin password, store that in the login keychain, and then, whenever needed, read the password with the security CLI, and pass that on inside the osascript.

[privacy-advo]

First, I would like to thank everbody contributing to DNSCrypt and it's surrounding ecosystem.
It appears to me that it is possible to create a workaround. Sadly I'm not able to deploy the solutions discussed in this thread.

Is there a plan to update bitbar-dnscrypt-proxy-switcher?
Thanks in advance

[nihj09]

I copied

osascript -e "do shell script \"networksetup -setdnsservers $service $wanted_resolvers\" with administrator privileges"

to line 166. And since I have a touchbar macbook, when I activate bitbar, it asks for my "Touch ID" instead of typing in the password all the time. This isn't as inconvenient as I thought. It does ask for the Touch ID after changing from "Use DNScrypt-proxy" to any other item but still works fine.

Thanks

[privacy-advo]

Thank you for the explanation. I will try to implement it in my system.

[privacy-advo]

I copied

osascript -e "do shell script \"networksetup -setdnsservers $service $wanted_resolvers\" with administrator privileges"

to line 166. And since I have a touchbar macbook, when I activate bitbar, it asks for my "Touch ID" instead of typing in the password all the time. This isn't as inconvenient as I thought. It does ask for the Touch ID after changing from "Use DNScrypt-proxy" to any other item but still works fine.

Thanks

Worked for me.
Thanks again.

[quadari]

Hi - thanks for this. One bug I found. If your network service name has a space in it, then this fails. You need to put quotes around $service in order to get it to work, I believe.
However, I couldn't figure out how to get that to work given that the command is already in quotes. Happy to hear if someone knows more about double-escaping quotes! Please post it.

My work around (which is probably suboptimal), is:

1. I changed line 166 to:
   sudo networksetup -setdnsservers "$service" $wanted_resolvers

2. I then edited my sudoers file so that my user is allowed to run networksetup. Specifically, from an administrator account (of which my user account isn't one), I ran sudo visudo. Then in that file, appended:
   my_user_name ALL = (root) NOPASSWD: /usr/sbin/networksetup

[jedisct1]

Thanks @quadari !

Another way to address this is to replace $service with \\\"$service\\\" (yes, that's a lot of \).