Re: Fixing wg-quick's DNS= directive with a hatchet

["Jason A. Donenfeld" <Jason@zx2c4.com>]

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.