- user - passt

Re: An unexpected error happens when login to passt bugzilla
by Stefano Brivio 16 Sep '25

16 Sep '25

On Tue, 16 Sep 2025 16:54:27 +0800 Han Han <hhan(a)redhat.com> wrote: > Hello, I got these errors when login to the passt bugzilla( > https://bugs.passt.top/index.cgi ): > An unexpected error occurred. This could be a temporary problem, or some > code is behaving incorrectly. If this problem persists, please email this > page to sbrivio(a)redhat.com with details of what you were doing at the time > this message appeared. Thanks for reporting this. In these cases, emailing me is enough, there's no need to share this on the list, just in case logs happen to include some private details. > URL: https://bugs.passt.top/index.cgi?GoAheadAndLogIn=Log%20in > > There was an error sending mail from '@bugs.passt.top' to 'hhan(a)redhat.com': > no sender > Traceback: > > at Bugzilla/Mailer.pm line 188. > Bugzilla::Mailer::MessageToMTA(...) called at Bugzilla/Mailer.pm line 231 > Bugzilla::Mailer::send_staged_mail(...) called at Bugzilla/DB.pm line 1320 > Bugzilla::DB::bz_commit_transaction(...) called at > Bugzilla/Auth/Persist/Cookie.pm line 58 > Bugzilla::Auth::Persist::Cookie::persist_login(...) called at > Bugzilla/Auth.pm line 158 > Bugzilla::Auth::_handle_login_result(...) called at Bugzilla/Auth.pm line 83 > Bugzilla::Auth::login(...) called at Bugzilla.pm line 342 > Bugzilla::login(...) called at /var/www/bugzilla/index.cgi line 21 I'll have a look and get back to you, off list. -- Stefano

1 1

passt: new version 2025_09_11.6cbcccc available
by Stefano Brivio 12 Sep '25

12 Sep '25

The new version with tag 2025_09_11.6cbcccc includes the following changes: 6cbcccc tcp: Store the owner connections for flags frames cd2e886 Reduce tcp_buf_discard size 8d2f8c4 tcp: Don't send FIN segment to guest yet if we have pending unacknowledged data bde1847 tcp: Fast re-transmit if half-closed, make TAP_FIN_RCVD path consistent 660cd69 tcp: Cast operands of sequence comparison macros to uint32_t before using them 25f9354 tcp: Don't try to transmit right after the peer shrank the window to zero c62fb08 tcp: Fix closing logic for half-closed connections e86d480 tcp: Rewind sequence when guest shrinks window to zero 1d502be tcp: Factor sequence rewind for retransmissions into a new function 2e3d93b tcp: FIN flags have to be retransmitted as well d363fb7 test: Fix the download link for debian-11-generic-ppc64el image c10d8c9 tcp_vu: Pass virtqueue pointer to tcp_vu_sock_recv() ed18d4c udp_vu: Pass virtqueue pointer to udp_vu_sock_recv() 6239915 vhost-user: Fix VHOST_USER_GET_QUEUE_NUM to return number of queues f9ee749 Add missing explicit PSH assignment 83afb88 Fix typo in doc comment 00e3580 test: Explicit specify forwarding ports for pasta in log rotation tests 3c44ef8 test: Allow exeter & podman tests to be parallel executed with BATS ffe34d2 test: Convert build tests to exeter a58e60e test: Run static checkers as exeter tests a283ef4 test: Extend test scripts to allow running exeter tests. ca38be0 packet: Add support for multi-vector packets 3e43e1a packet: Refactor vhost-user memory region handling 1602aa2 packet: remove unused parameter from PACKET_POOL_DECL() 7ae35a9 packet: remove PACKET_POOL() and PACKET_POOL_P() 2eb845a ndp: use iov_tail rather than pool 76de6f5 icmp: use iov_tail rather than pool 42a108b dhcpv6: use iov_tail rather than pool 3a261fd dhcp: use iov_tail rather than pool c977d1f arp: use iov_tail rather than pool 7e25351 packet: rename packet_data() to packet_get() 9505908 tap: Convert tap6_handler() to iov_tail a26c608 tap: Convert tap4_handler() to iov_tail 20cd6d0 ip: Use iov_tail in ipv6_l4hdr() 84a4d3e dhcp: Convert to iov_tail feb3330 dhcpv6: Use iov_tail in dhcpv6_opt() c4cad31 dhcpv6: Convert to iov_tail 54f15c6 dhcpv6: Extract sending of NotOnLink status 1932832 dhcpv6: move offset initialization out of dhcpv6_opt() d2c33f4 tcp: Convert tcp_data_from_tap() to use iov_tail 87cc7ab tcp: Convert tcp_tap_handler() to use iov_tail d9604f0 udp: Convert to iov_tail e45bf13 icmp: Convert to iov_tail f8860bb ndp: Convert to iov_tail 1fc944c arp: Convert to iov_tail 6bada9a packet: Add packet_data() de469a3 packet: Use iov_tail with packet_add() 720d8fc tap: Use iov_tail with tap_add_packet() 70b9c0c iov: Update IOV_REMOVE_HEADER() and IOV_PEEK_HEADER() 066e6b1 iov: Introduce iov_tail_clone() and iov_drop_header(). ea3dd28 arp: Don't mix incoming and outgoing buffers eef5bb8 build: Fix errors of TCP_REPAIR_* undeclared b4fc6cd treewide: Flush pcap and log files, if used, before exiting https://passt.top/passt/log/?qt=range&q=2025_08_05.309eefd..2025_09_11.6cbc… Packages: - Alpine Linux: https://pkgs.alpinelinux.org/packages?name=passt - Arch Linux: https://www.archlinux.org/packages/extra/x86_64/passt/ https://archlinuxarm.org/packages/aarch64/passt https://archlinuxarm.org/packages/armv7h/passt - Chimera: https://pkgs.chimera-linux.org/packages?name=passt - Clear Linux: https://github.com/clearlinux-pkgs/passt/ - Copr (CentOS Stream, EPEL, Fedora, Mageia): https://copr.fedorainfracloud.org/coprs/sbrivio/passt/build/9548830/ permanent mirror: https://passt.top/builds/copr/0^20250911.g6cbcccc/ - Debian tracker: https://tracker.debian.org/pkg/passt - Fedora updates: https://bodhi.fedoraproject.org/updates/?packages=passt - Gentoo versions: https://packages.gentoo.org/packages/net-misc/passt - GNU Guix: https://packages.guix.gnu.org/packages/passt/ - Homebrew: https://formulae.brew.sh/formula/passt - NixOS: https://github.com/NixOS/nixpkgs/tree/nixos-unstable/pkgs/by-name/pa/passt - openSUSE: https://software.opensuse.org/package/passt - OpenMandriva: https://github.com/OpenMandrivaAssociation/passt/tree/master - PLD Linux: https://git.pld-linux.org/cgi-bin/gitweb.cgi?p=packages/passt.git - Solus: https://github.com/getsolus/packages/tree/main/packages/p/passt - Ubuntu tracker: https://launchpad.net/ubuntu/+source/passt - Void Linux: https://voidlinux.org/packages/?q=passt - Static builds: - Package for other RPM-based distributions, x86_64 only: https://passt.top/builds/latest/x86_64/passt-g6cbcccc-1.x86_64.rpm - x86_64 static binaries: https://passt.top/builds/latest/x86_64/ - Debian package, from x86_64 static build: https://passt.top/builds/latest/x86_64/passt_6cbcccc-1_all.deb -- Stefano

1 0

passt: new version 2025_08_05.309eefd available
by Stefano Brivio 06 Aug '25

06 Aug '25

The new version with tag 2025_08_05.309eefd includes the following changes: 309eefd selinux: pasta accesses /etc/resolv.conf a878286 treewide: By default, don't quit source after migration, keep sockets open 79de81e test: Deal with /bin, /sbin unification in Fedora 3757ea3 style: Add parentheses to function names in comments 9e0423e style: Fix 'Return' comment style https://passt.top/passt/log/?qt=range&q=2025_06_11.0293c6f..2025_08_05.309e… Packages: - Alpine Linux: https://pkgs.alpinelinux.org/packages?name=passt - Arch Linux: https://www.archlinux.org/packages/extra/x86_64/passt/ https://archlinuxarm.org/packages/aarch64/passt https://archlinuxarm.org/packages/armv7h/passt - Chimera: https://pkgs.chimera-linux.org/packages?name=passt - Clear Linux: https://github.com/clearlinux-pkgs/passt/ - Copr (CentOS Stream, EPEL, Fedora, Mageia): https://copr.fedorainfracloud.org/coprs/sbrivio/passt/build/9381856/ permanent mirror: https://passt.top/builds/copr/0^20250805.g309eefd/ - Debian tracker: https://tracker.debian.org/pkg/passt - Fedora updates: https://bodhi.fedoraproject.org/updates/?packages=passt - Gentoo versions: https://packages.gentoo.org/packages/net-misc/passt - GNU Guix: https://packages.guix.gnu.org/packages/passt/ - Homebrew: https://formulae.brew.sh/formula/passt - NixOS: https://github.com/NixOS/nixpkgs/tree/nixos-unstable/pkgs/by-name/pa/passt - openSUSE: https://software.opensuse.org/package/passt - OpenMandriva: https://github.com/OpenMandrivaAssociation/passt/tree/master - PLD Linux: https://git.pld-linux.org/cgi-bin/gitweb.cgi?p=packages/passt.git - Solus: https://github.com/getsolus/packages/tree/main/packages/p/passt - Ubuntu tracker: https://launchpad.net/ubuntu/+source/passt - Void Linux: https://voidlinux.org/packages/?q=passt - Static builds: - Package for other RPM-based distributions, x86_64 only: https://passt.top/builds/latest/x86_64/passt-g309eefd-1.x86_64.rpm - x86_64 static binaries: https://passt.top/builds/latest/x86_64/ - Debian package, from x86_64 static build: https://passt.top/builds/latest/x86_64/passt_309eefd-1_all.deb -- Stefano

1 0

Re: Issues when using pasta with bubblewrap
by David Gibson 23 Jul '25

23 Jul '25

On Wed, Jul 09, 2025 at 01:54:36AM +0200, Lisa Gnedt via user wrote: > Date: Wed, 9 Jul 2025 01:54:36 +0200 > From: Lisa Gnedt <lisa+passt-user(a)gnedt.at> > To: Stefano Brivio <sbrivio(a)redhat.com> > CC: passt-user(a)passt.top, Paul Holzinger <pholzing(a)redhat.com> > Subject: Re: Issues when using pasta with bubblewrap > List-Id: "For passt users: support, questions and answers" > <passt-user.passt.top> > > Hi Stefano, Hi Lisa, I'm back from extended leave and looking at this thread as Stefano suggested. > Thanks for you fast feedback! > > On 2025-07-07 18:19, Stefano Brivio wrote: > > For context, "this" is: always join the user namespace owning a network > > namespace. > > Yes, exactly. > > > It looks reasonable (and desirable) to me, but I'm not sure how / why > > it breaks the --userns parameter. > > In the case, where a PID is supplied, it misuses the userns variable > and sets it to the path of the network namespace and then always calls > the ioctl NS_GET_USERNS to get the owning user namespace. > However, the userns variable might also be manually set via the --userns > option, whereas we expect users to set this parameter to the path of a > user namespace. The ioctl NS_GET_USERNS returns the parent user namespace > when a user namespace is given. Therefore, we join the parent user > namespace with this patch instead of joining the given user namespace. > > > We should probably never do this when --netns-only is given (that's > > Podman's case, for example). > > I agree, it does not make sense to join a user namespace, when a user > explicitly only wants to join the network namespace. So.. I think this discussion is missing a crucial point: In order to operate, pasta *must* end up in the userns owning the guest's netns. --userns and --netns-only aren't exceptions to that, they're just different ways of locating the correct userns. In PID/--netns mode, I think NS_GET_USERNS makes --userns entirely obsolete. No need to have the user tell us the right userns when we have a reliable way to discover it. It also makes --netns-only obsolete. The slight wrinkle here is that you can't re-enter the userns you're already in. So, we have to test if the ns returned by NS_GET_USERNS is the one we already inhabit. According to namespaces(7) we can do that by using fstat/stat and checking the device and inode of the fd from NS_GET_USERNS versus that of /proc/self/ns/user. So, I think we should straight out deprecate --userns and --netns-only for the PID/--netns case. NS_GET_USERNS is basically an all around better solution. For COMMAND mode, NS_GET_USERNS can't help us, because we need to locate the userns before we can create the netns. We still have the three options of where to create the new netns: * In a new userns (default) * In our current userns (--netns-only) * In a different existing userns (--userns) With that in mind, opinions on the specific behaviours we should aim for below. > > It would be good to have a way to "cleanly" exclude this new behaviour, > > but, once we add the NS_GET_USERNS trick, --netns-only doesn't exactly > > get us back to the previous behaviour. What about --userns-from-pid or > > something like that? That name isn't great though. > > I agree that this would be one of the possible solutions. It would > enable the use either with PID or with the --netns option. > Maybe --userns-from-netns would be better? Somehow it would be cool to > include the relationship between userns and netns more concretely like > --join-owning-userns-from-netns, but on the other hand it is also a bit > too long. > > However, I am not sure, if it is really necessary to have a separate > CLI option. Maybe it would also be a fine new default behavior just for > the case when a PID is specified, but no network or user namespace is > explicitly given. > If anyone really needs the old behavior, it is still possible to specify > the user namespace explicitly and, therefore, deactivate the new > behavior. > It seems that podman uses the --netns option, so it should be fully > unaffected by this proposed change of default behavior. > > I am fine with both solutions. I thought a bit more about the current > and changed behavior by iterating trough the possible combinations of > options with my code changes in mind. I hope this is not too much, but > it also uncovered a few already existing strange edge cases. Here's what I think we should do for each case (many of these match Lisa's suggestions). This aims to keep old kernel compatibility as best we can. > CLI options -> behavior > ---------------------------------------------- > > PID -> new behavior (netns from PID, userns from netns from PID with fallback to userns from PID) netns from pid, userns from NS_GET_USERNS. If NS_GET_USERNS fails, userns from PID. > --netns-only PID -> new behavior (netns from PID, userns from netns from PID with fallback to userns from PID) ***2 > It looks like this is currently already a strange behavior, as it would get the netns and userns from PID. netns from pid. Check NET_GET_USERNS, if it succeeds, but isn't the same as our current namespace, exit with error. If it fails, userns from PID. > --userns X PID -> existing behavior (netns from PID, userns from option) netns from pid. Check NET_GET_USERNS, if it succeeds, but isn't the same as given userns, exit with error. If it fails userns from option. > --userns X --netns-only PID -> new behavior (netns from PID, userns from netns from PID with fallback to userns from PID - strange) ***1 > It looks like this is currently already a strange behavior, as it would also get the userns from PID. Fail with an error. This already makes no sense, because we're giving contradictory instructions on what userns to use. > --netns-only --userns X PID -> existing behavior (netns from PID, userns from option - strange) ***1 Same case as previous. > --netns X PID -> existing behavior (invalid) > (skipping further combination with --netns and PID) Fail with an error (as we already do). > --netns X -> existing behavior (netns from option, no userns) netns from option, userns from NS_GET_USERNS. If NS_GET_USERNS fails, exit with error. > --netns X --netns-only -> existing behavior (netns from option, no userns) netns from option. Check NS_GET_USERNS, if it succeeds but isn't the same as current namespace, exit with error. If it fails, fall back to keeping current userns and hope for the best (i.e. existing behaviour). > --netns X --userns Y -> existing behavior (netns from option, userns from option) netns from option. Check NS_GET_USERNS, if it succeeds but isn't the same as given userns, exit with error. If it fails, fall back to using given userns and hope for the best (existing behaviour). > --netns X --userns Y --netns-only -> existing behavior (netns from option, no userns - a bit strange) ***1 Fail with an error. > --netns X --netns-only --userns Y -> existing behavior (netns from option, userns from option - strange) ***1 Same case as previous. > COMMAND -> existing behavior (new netns, new userns) Existing behaviour. > --netns-only COMMAND -> existing behavior (new netns, no userns) Existing behaviour. > --userns X COMMAND -> existing behavior (new netns, userns from option) Existing behaviour. > --userns X --netns-only COMMAND -> existing behavior (new netns, no userns - a bit strange) ***1 Fail with an error. > --netns-only --userns X COMMAND -> existing behavior (new netns, userns from option - strange) ***1 Fail with an error. > --netns X COMMAND -> existing behavior (invalid) > (skipping further combination with --netns and COMMAND) Fail with an error (which is existing behaviour). > Although it is not directly related to the change I am proposing, it > might make sense to clean up the CLI option behavior a bit. I would > argue to forbid --userns in combination with --netns-only completely > (everything marked with ***1). As noted above, I agree. This already makes no sense. > Furthermore, --netns-only PID seems to be currently broken (marked > with ***2). I think the netns_only variable (or use_userns how it is called > inside isolate.c) should most likely get higher priority than the userns > variable itself. This should fix the behavior to only use the netns > from PID and no userns. Oh, interesting. As above, I think we should deprecate this case anyway (with NS_GET_USERNS + checking if we're already in the right namespace, it's not necessary). If it happens to already be broken, that gives us an excuse to just remove support without going through the deprecation process. > > Now, 4.9 feels "old" enough, but pasta used to run on a 3.13 kernel a > > while ago, then a few things were (inadvertently) broken. But it > > "almost" does. Couldn't we just add a fallback for the case where > > NS_GET_USERNS fails? You're already handling the error. You could just > > print a warning and continue instead of calling die_perror()... For the plain 'PID' case this makes sense. For other cases it's murkier - we may have no reasonable fallback, or the "fallback" might contradict the behaviour we'd have in the case that NS_GET_USERNS succeeds, which would be weird. I've opined on each case separately above. > Yes, it makes sense to implement a fallback when changing the default > behavior. If it will become a separate option, it seems counter-intuitive > to have an automatic fallback. > I just thought it might be best to first discuss the wanted behavior before > starting to implement more complex changes. Yes, that makes sense. Are you comfortable with implementing the behaviour I've described above? I could tackle this, but I'd love for someone else to do it instead. If you are happy to tackle it, two small suggestions: - start with a preliminary patch to make combining --netns-only and --userns an error. That never made sense and making it explicit is a good idea regardless of what else we do. - Another preliminary patch can add a "namespaces_equal" helper, since that will ne needed in a number of places. -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson

1 0

Re: Issues when using pasta with bubblewrap
by Stefano Brivio 20 Jul '25

20 Jul '25

[Cc'ing Paul as Podman maintainer, thread at: https://archives.passt.top/passt-user/671252c8-88f6-45b7-b719-b82786e84bb7@…] On Sun, 6 Jul 2025 19:08:46 +0200 Lisa Gnedt via user <passt-user(a)passt.top> wrote: > Hi, > > On 2025-07-06 17:15, Lisa Gnedt wrote: > > 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]. > > I just wrote a hacky patch as proof-of-concept of this idea. > It is working for me fine in both testcases. > However, in its current form it breaks the --userns parameter. But it should not be too hard to address this issue. > > I am not sure, what kernel version compatibility you are targeting, since the ioctl is only available since Linux 4.9. > Would it be an option for you to make it the default behavior when a PID is specified? > >From my perspective this should be the expected behavior and should not break any previously working use case. I finally had a second look, a bit quicker than I wanted but I think I grasped the issue. For context, "this" is: always join the user namespace owning a network namespace. It looks reasonable (and desirable) to me, but I'm not sure how / why it breaks the --userns parameter. We should probably never do this when --netns-only is given (that's Podman's case, for example). It would be good to have a way to "cleanly" exclude this new behaviour, but, once we add the NS_GET_USERNS trick, --netns-only doesn't exactly get us back to the previous behaviour. What about --userns-from-pid or something like that? That name isn't great though. Now, 4.9 feels "old" enough, but pasta used to run on a 3.13 kernel a while ago, then a few things were (inadvertently) broken. But it "almost" does. Couldn't we just add a fallback for the case where NS_GET_USERNS fails? You're already handling the error. You could just print a warning and continue instead of calling die_perror()... > diff --git a/conf.c b/conf.c > index 36845e2..cd67e7a 100644 > --- a/conf.c > +++ b/conf.c > @@ -642,7 +642,7 @@ static void conf_pasta_ns(int *netns_only, char *userns, char *netns, > > if (!*userns) { > if (snprintf_check(userns, PATH_MAX, > - "/proc/%ld/ns/user", pidval)) > + "/proc/%ld/ns/net", pidval)) > die_perror("Can't build userns path"); > } > } > diff --git a/isolation.c b/isolation.c > index bbcd23b..cbfe0f0 100644 > --- a/isolation.c > +++ b/isolation.c > @@ -81,6 +81,7 @@ > #include <linux/audit.h> > #include <linux/capability.h> > #include <linux/filter.h> > +#include <linux/nsfs.h> > #include <linux/seccomp.h> > > #include "util.h" > @@ -254,6 +255,14 @@ void isolate_user(uid_t uid, gid_t gid, bool use_userns, const char *userns, > if (ufd < 0) > die_perror("Couldn't open user namespace %s", userns); > > + int real_ufd; > + real_ufd = ioctl(ufd, NS_GET_USERNS); > + if (real_ufd < 0) > + die_perror("Couldn't get user namespace from network namespace %s", userns); > + > + close(ufd); > + ufd = real_ufd; > + > if (setns(ufd, CLONE_NEWUSER) != 0) > die_perror("Couldn't enter user namespace %s", userns); > -- Stefano

2 3

Re: Issues when using pasta with bubblewrap
by Stefano Brivio 07 Jul '25

07 Jul '25

Hi Lisa, On Sun, 6 Jul 2025 19:08:46 +0200 Lisa Gnedt via user <passt-user(a)passt.top> wrote: > Hi, > > On 2025-07-06 17:15, Lisa Gnedt wrote: > > 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]. > > I just wrote a hacky patch as proof-of-concept of this idea. > It is working for me fine in both testcases. > However, in its current form it breaks the --userns parameter. But it should not be too hard to address this issue. > > I am not sure, what kernel version compatibility you are targeting, since the ioctl is only available since Linux 4.9. Thanks for reporting this and for the draft. I didn't look into your issue and patch yet, I plan to get to it later today, but just as a quick answer to this point: the earlier the better, not everything is reasonable, but 4.9 should be. And yes, patches for compatibility are always warmly welcome. -- Stefano

1 0

Issues when using pasta with bubblewrap
by Lisa Gnedt 06 Jul '25

06 Jul '25

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

1 1

Re: Install pasta network with Linux kernel 5.4
by Stefano Brivio 04 Jul '25

04 Jul '25

Hi Thiru, On Fri, 4 Jul 2025 01:43:36 +0000 Thiru Vajjala via user <passt-user(a)passt.top> wrote: > Hi Team, > > I’m trying to use pasta networking in rootless mode instead of > slirp4netns. But pasta module not installed when Podman installed for > Linux kernel .5.4 . RED HAT / Oracle Linux 8. > > But for Oracle Linux 8 with kernel version 6.4 . pasta module > installed default. Is it possible to build from source and install in > Oracle Linux 8? If yes can you please share details Yes, see: https://bugs.passt.top/show_bug.cgi?id=121 ...it would be nice if somebody could contribute (and test!) a proper patch for it (see https://bugs.passt.top/show_bug.cgi?id=121#c4 specifically) so that we can finally fix this for everybody. -- Stefano

1 0

Install pasta network with Linux kernel 5.4
by Thiru Vajjala 04 Jul '25

04 Jul '25

Hi Team, I’m trying to use pasta networking in rootless mode instead of slirp4netns. But pasta module not installed when Podman installed for Linux kernel .5.4 . RED HAT / Oracle Linux 8. But for Oracle Linux 8 with kernel version 6.4 . pasta module installed default. Is it possible to build from source and install in Oracle Linux 8? If yes can you please share details Thanks, Thiru

1 0

passt: new version 2025_06_11.0293c6f available
by Stefano Brivio 11 Jun '25

11 Jun '25

The new version with tag 2025_06_11.0293c6f includes the following changes: 0293c6f fedora: Hide restorecon(8) errors in post-transaction scriptlet 98da8a9 fedora: Add container-selinux as dependency for passt-selinux https://passt.top/passt/log/?qt=range&q=2025_06_06.754c6d7..2025_06_11.0293… Packages: - Alpine Linux: https://pkgs.alpinelinux.org/packages?name=passt - Arch Linux: https://www.archlinux.org/packages/extra/x86_64/passt/ https://archlinuxarm.org/packages/aarch64/passt https://archlinuxarm.org/packages/armv7h/passt - Chimera: https://pkgs.chimera-linux.org/packages?name=passt - Clear Linux: https://github.com/clearlinux-pkgs/passt/ - Copr (CentOS Stream, EPEL, Fedora, Mageia): https://copr.fedorainfracloud.org/coprs/sbrivio/passt/build/9153303/ permanent mirror: https://passt.top/builds/copr/0^20250611.g0293c6f/ - Debian tracker: https://tracker.debian.org/pkg/passt - Fedora updates: https://bodhi.fedoraproject.org/updates/?packages=passt - Gentoo versions: https://packages.gentoo.org/packages/net-misc/passt - GNU Guix: https://packages.guix.gnu.org/packages/passt/ - Homebrew: https://formulae.brew.sh/formula/passt - NixOS: https://github.com/NixOS/nixpkgs/tree/nixos-unstable/pkgs/by-name/pa/passt - openSUSE: https://software.opensuse.org/package/passt - OpenMandriva: https://github.com/OpenMandrivaAssociation/passt/tree/master - PLD Linux: https://git.pld-linux.org/cgi-bin/gitweb.cgi?p=packages/passt.git - Solus: https://github.com/getsolus/packages/tree/main/packages/p/passt - Ubuntu tracker: https://launchpad.net/ubuntu/+source/passt - Void Linux: https://voidlinux.org/packages/?q=passt - Static builds: - Package for other RPM-based distributions, x86_64 only: https://passt.top/builds/latest/x86_64/passt-g0293c6f-1.x86_64.rpm - x86_64 static binaries: https://passt.top/builds/latest/x86_64/ - Debian package, from x86_64 static build: https://passt.top/builds/latest/x86_64/passt_0293c6f-1_all.deb -- Stefano

1 0