Wrong DNS when launched from existing network namespace

[vmedea]

Linux distribution and version

PureOS 9 (based on Debian stretch).

Flatpak version

Flatpak 1.2.4

Description of the problem

When starting flatpak run from a Linux network namespace (ip netns exec <ns>…), the application sandbox will contain a /etc/resolv.conf that symlinks to the global DNS configuration instead of /etc/netns/<ns>/resolv.conf.

This causes DNS lookups to fail for the application!

Steps to reproduce

For example, start a VPN-tunneled network namespace with (openvpn-netns)[https://github.com/pekman/openvpn-netns] or similar, anything that sets up a completely different network configuration than the host will work—then start flatpak firefox in it:

#  ip netns add vpn
#  ip netns exec vpn ip addr add 127.0.0.1/8 dev lo
#  ip netns exec vpn ip link set lo up
# export NETNS=vpn
# openvpn-netns  --config <config> --daemon --log /tmp/vpn.log
# ip netns exec vpn sudo -i -u <user> flatpak run org.mozilla.firefox

The resulting firefox will run inside the namespace however the DNS will be wrong so it doesn't show any pages.

It's possible to work around this by entering the flatpak PID's filesystem namespace and correct the /etc/resolv.conf with nsenter:

#!/bin/bash
namespace=$1
conf="/etc/netns/${namespace}/resolv.conf"
newns=$(grep nameserver $conf)
echo "[${namespace}] ${newns}"
for pid in $(ip netns pids "${namespace}"); do
    nsenter -m -t "${pid}" bash -c \
        "if [ \"\$(readlink /etc/resolv.conf)\" == '/run/host/monitor/resolv.conf' ]; then
            echo '${pid}: rewriting resolv.conf';
            rm /etc/resolv.conf;
            echo '${newns}' > /etc/resolv.conf;
        fi"
done

But I think ideally it should just work. I know flatpak has a built-in option to run in a new network namespace without any networking, but this is not what I'm trying to do.

[vmedea]

Looks like this was fixed along the way?
With Flatpak 1.6.3 (at least on Ubuntu 20.04) the problem doesn't happen it picks up the network namespace's resolve.conf.

[13s5lp]

I'm having trouble with this using Flatpak 1.12.7:

Shows netns resolv.conf: sudo ip netns exec "$NSNAME" runuser -u "$(whoami)" -- flatpak run --command=cat org.mozilla.firefox /etc/resolv.conf

Shows host resolv.conf: sudo --preserve-env=DBUS_SESSION_BUS_ADDRESS,XDG_RUNTIME_DIR ip netns exec "$NSNAME" runuser -u "$(whoami)" -- flatpak run --command=cat org.mozilla.firefox /etc/resolv.conf

Firefox launches without those environment variables, but unfortunately com.github.Eloston.UngoogledChromium won't launch unless they're set, so I can't find a way to use the netns resolv.conf with Chromium.

[Fincer]

After some investigation, I have solved this issue with the following network namespace script bundle: https://github.com/Fincer/network_namespaces

And, for com.github.Eloston.UngoogledChromium, you should prepend the executable command with dbus-launch. I saw no negative impacts of using dbus-launch for all Flatpak executables, although I don't know whether there are side effects of using it that way.

[anzix]

According to my tests, using the Flatpack versions of Ungoogled Chromium and Firefox, both still cannot work with DNS Network Namespace /etc/netns/<netns_name>/resolv.conf. Accordingly, because of this, there is no Internet connection. I decided to use two methods:

1. The first one described by @Fincer. His method is to remove the variables DBUS_SESSION_BUS_ADDRESS XDG_RUNTIME_DIR using the unset command and then use dbus-launch (before flatpak run) to launch. And even though it made DNS resolver Network Namespace work, however, it breaks D-Bus, even running with dbus-launch does not fix it.

2. The second method is to use dbus-launch as a trigger on the first launch and remove it on the second launch to restore operation.
   
   As soon as I add dbus-launch to the Flatpak launch line, the bind in /etc/netns/vpn/resolv.conf works and, accordingly, the internet too, but there is a big catch. The fact is that dbus-launch works as a trigger and when you run the program with it again, half of the things related to D-Bus break down, such as the xdg-document-portal, which is responsible for viewing local documents inside the browser, all because when you start an already running dbus, the second dbus starts breaking the work programs. This is how it is solved: after the first launch, for the second launch, I need to remove dbus-launch from the Flatpak launch line and after that the program remains with dbus-launch enabled and works surprisingly very well and stably, no D-Bus errors at all.

Although my second option is more viable, it is a crutch, because I cannot normally use custom desktop shortcuts with the prescribed launch of netns

This is how I run netns

# Using run0
run0 --setenv="DISPLAY=${DISPLAY}" --setenv="XAUTHORITY=${XAUTHORITY}" --property "NetworkNamespacePath=/var/run/netns/vpn" --property "BindReadOnlyPaths=/etc/netns/vpn/resolv.conf:/etc/resolv.conf:norbind" -u $(whoami) -- /usr/bin/flatpak run --branch=stable --arch=x86_64 --command=/app/bin/chromium --file-forwarding io.github.ungoogled_software.ungoogled_chromium

# Using pkexec
pkexec env DISPLAY=${DISPLAY} XAUTHORITY=${XAUTHORITY} ip netns exec vpn runuser -u $(whoami) -- /usr/bin/flatpak run --branch=stable --arch=x86_64 --command=/app/bin/chromium --file-forwarding io.github.ungoogled_software.ungoogled_chromium

Just in case, I say that my netns configuration is correct and working and it works great with native distribution packages

Flatpak 1.15.10, Arch Linux distribution

[COC-Compliant]

The issue here is that flatpak communicates with a helper executable through the dbus. This helpers runs inside the main network namespace and keeps track of the network configuration files like resolv.conf and sends updates to the flatpak.

To fix this, a flag could be added to disable the use of a helper processs (like flatpak does for its test cases).

Creating a new dbus with dbus-launch may fix the issue but causes all other dbus features to break as well (E.g. kwallet, desktop interactions and notification)

I usually just dnat the wrong dns server to the correct one with nftables

#!/usr/sbin/nft -f
# params  $ip_external

table inet filter {
    chain dns_redirect { 
        type nat hook output priority dstnat;
        ip daddr 10.0.0.0/8 tcp dport 53 dnat ip to $ip_external
        ip daddr 10.0.0.0/8 udp dport 53 dnat ip to $ip_external
    }
}