From: Lisa Gnedt <lisa+passt-user@gnedt.at>
To: passt-user@passt.top
Subject: Issues when using pasta with bubblewrap
Date: Sun, 6 Jul 2025 17:15:58 +0200 [thread overview]
Message-ID: <671252c8-88f6-45b7-b719-b82786e84bb7@gnedt.at> (raw)
Hi,
I am working on integrating pasta into NixPak [1], which boils down to
using pasta together with bubblewrap [2].
It basically works, but in a specific edge-case I am running into problems.
The edge-case is when bubblewrap creates two layers of user namespaces.
What I am basically doing is let bubblewrap create a new network
namespace and then start pasta to create the interfaces accordingly.
In the NixPak support, I am doing this in coordination with bubblewrap
to start pasta before the actual application is launched.
However, here are a few minimum examples for re-producing the problem.
All testcases were run using pasta 2025_06_11.0293c6f on Linux
6.12.34-hardened1.
Testcase A: Single layer of user namespaces -> Works
----------------------------------------------------
First, I start the bwrap sandbox with a new network namespace:
$ bwrap --unshare-all --ro-bind / / /bin/sh
sh-5.2$ ip -br a
lo UNKNOWN 127.0.0.1/8 ::1/128
In another terminal window, I start pasta with the pid of the bubblewrap
child which runs inside the new Linux namespaces:
$ pasta --config-net --no-dhcp --no-dhcpv6 --no-ndp --no-ra --no-map-gw
--tcp-ns none --udp-ns none --tcp-ports none --udp-ports none
--ns-ifname eth0 --address 192.168.1.100 --netmask 255.255.255.0
--gateway 192.168.1.1 --mac-addr 52:54:00:12:34:56 --dns-forward
192.168.1.1 --search none 389267
No interfaces with usable IPv6 routes
Template interface: eno2 (IPv4)
Namespace interface: eth0
MAC:
host: 52:54:00:12:34:56
DNS:
192.168.1.1
Then, I go back to the bwrap sandbox and check that the network
namespace is now fully set up:
sh-5.2$ ip -br a
lo UNKNOWN 127.0.0.1/8 ::1/128
eth0 UNKNOWN 192.168.1.100/24
fe80::bceb:d3ff:fe9c:d037/64
Testcase B: Two layers of user namespaces -> Fails directly, but works
with nsenter
-----------------------------------------------------------------------------------
First, I start again the bwrap sandbox with a new network namespace and
the option --dev which is one case where bubblewrap creates two layers
of user namespaces:
$ bwrap --unshare-all --ro-bind / / --dev /dev /bin/sh
sh-5.2$ ip -br a
lo UNKNOWN 127.0.0.1/8 ::1/128
In another terminal window, I try to start pasta with the pid of the
bubblewrap child which runs inside the new Linux namespaces:
$ pasta --config-net --no-dhcp --no-dhcpv6 --no-ndp --no-ra --no-map-gw
--tcp-ns none --udp-ns none --tcp-ports none --udp-ports none
--ns-ifname eth0 --address 192.168.1.100 --netmask 255.255.255.0
--gateway 192.168.1.1 --mac-addr 52:54:00:12:34:56 --dns-forward
192.168.1.1 --search none 390352
No interfaces with usable IPv6 routes
Couldn't switch to pasta namespaces: Operation not permitted
This does not work, since pasta joined the second layer user namespace
which does not own the network namespace.
What works although is if I join the first layer user namespace with
nsenter and then let pasta run:
$ nsenter -t 390352 -U --preserve-credentials --user-parent -- pasta
--config-net --no-dhcp --no-dhcpv6 --no-ndp --no-ra --no-map-gw --tcp-ns
none --udp-ns none --tcp-ports none --udp-ports none --ns-ifname eth0
--address 192.168.1.100 --netmask 255.255.255.0 --gateway 192.168.1.1
--mac-addr 52:54:00:12:34:56 --dns-forward 192.168.1.1 --search none
--netns /proc/390352/ns/net
No interfaces with usable IPv6 routes
Template interface: eno2 (IPv4)
Namespace interface: eth0
MAC:
host: 52:54:00:12:34:56
DNS:
192.168.1.1
Then, I go back to the bwrap sandbox and check that the network
namespace is now fully set up:
sh-5.2$ ip -br a
lo UNKNOWN 127.0.0.1/8 ::1/128
eth0 UNKNOWN 192.168.1.100/24 fe80::54fa:e1ff:fe87:79e/64
Ideas for Solutions
-------------------
I am trying to find a solution that works with both testcases (single
and two layers of user namespaces).
My idea would be to always join the owning user namespace of the network
namespace.
I tried to simulate this with nsenter, but for some reason I am not
getting pasta working for the single layer user namespace (testcase A):
$ bwrap --unshare-all --ro-bind / / /bin/sh
sh-5.2$ ip -br a
lo UNKNOWN 127.0.0.1/8 ::1/128
$ nsenter -t 390424 -U --preserve-credentials -- pasta --config-net
--no-dhcp --no-dhcpv6 --no-ndp --no-ra --no-map-gw --tcp-ns none
--udp-ns none --tcp-ports none --udp-ports none --ns-ifname eth0
--address 192.168.1.100 --netmask 255.255.255.0 --gateway 192.168.1.1
--mac-addr 52:54:00:12:34:56 --dns-forward 192.168.1.1 --search none
--netns /proc/390424/ns/net
No interfaces with usable IPv6 routes
Couldn't switch to pasta namespaces: Operation not permitted
While experimenting with this, I wondered if it is a scenario that pasta
would like to support out of the box.
It might be easier to get it correct when directly controlling all
syscalls involved and not have to mix and match multiple tools.
Since Linux 4.9 it seems to be possible to get the owning user namespace
of a network namespace with the ioctl NS_GET_USERNS [3].
Do you consider looking into this or would you accept a patch for adding
support for this?
Best regards,
Lisa Gnedt
[1] https://github.com/nixpak/nixpak
[2] https://github.com/containers/bubblewrap
[3] https://man7.org/linux/man-pages/man2/ns_get_userns.2const.html
next reply other threads:[~2025-07-06 15:16 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-06 15:15 Lisa Gnedt [this message]
2025-07-06 17:08 ` Issues when using pasta with bubblewrap Lisa Gnedt
[not found] ` <175188240057.3062894.4319502484182397394@maja>
2025-07-07 10:56 ` Stefano Brivio
2025-07-07 16:19 ` Stefano Brivio
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=671252c8-88f6-45b7-b719-b82786e84bb7@gnedt.at \
--to=lisa+passt-user@gnedt.at \
--cc=passt-user@passt.top \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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 IMAP folder(s).