Open
Description
This is potentially a big issue. It seems to happen by "accident" pointing to the sandboxing provided by vopono being quite porose. Here's the terminal output:
$ vopono exec --provider mullvad --server sweden "qbittorrent"
2021-03-07T16:18:39.239Z INFO vopono::util > Calling sudo for elevated privileges, current user will be used as default user
[sudo] password for dani:
2021-03-07T16:18:47.062Z INFO vopono::util > Chosen config: /home/dani/.config/vopono/mv/wireguard/sweden-se19.conf
2021-03-07T16:18:47.065Z INFO vopono::exec > Using existing namespace: vopono_mv_sweden, will not modify firewall rules
2021-03-07T16:18:47.065Z INFO vopono::netns > Using existing network namespace: vopono_mv_sweden
2021-03-07T16:18:47.143Z INFO vopono::exec > Application qbittorrent launched in network namespace vopono_mv_sweden with pid 96151
(qbittorrent:96152): dbind-WARNING **: 17:18:47.176: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-UPvZ3RgVN4: Connection refused
dani@gorillo:~$
As you see, the process exits. And after it's exited, the qBittorrent GUI comes online. And...
$ ps ax | grep qbittorrent
87697 ? Sl 0:28 qbittorrent
That PID is not 96151! Through some kind of trick, the sandboxed qBittorrent process fails, maybe due to the dbus refusal, and... a completely different, non-sandboxed process is pulled up.
The reason I know this to be true is that I tested it with the Mullvad ip leak tool, and it does not go through the vpn at all.
Metadata
Metadata
Assignees
Labels
No labels