From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=V5JkTwvB; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id 982925A0271 for ; Mon, 12 Jan 2026 09:20:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1768206034; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WJTPLpoOGqnpZo42YJZ0PyowW6TzY3AzhRv0Pplyg1g=; b=V5JkTwvBTITayhpKCxcGDOHEUZRG1/Ql6djHPhRqtJA3NDGwpR5IyWgApTQPZD39ytY1Ml VOEW/WwbnoWQfyMJwWzdslvd7X/EAhPzxbhOvFbHBjmkWxNq+v7mZ0tStAKxRib/ZjglWm PSRbc84LGXRnZnQa0hBGP5EmewbN51Q= Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-86-nKpoLhZ-NimrvD5anHMbqQ-1; Mon, 12 Jan 2026 03:20:33 -0500 X-MC-Unique: nKpoLhZ-NimrvD5anHMbqQ-1 X-Mimecast-MFC-AGG-ID: nKpoLhZ-NimrvD5anHMbqQ_1768206032 Received: by mail-ed1-f71.google.com with SMTP id 4fb4d7f45d1cf-64cfe5a2147so9451068a12.3 for ; Mon, 12 Jan 2026 00:20:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768206032; x=1768810832; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=WJTPLpoOGqnpZo42YJZ0PyowW6TzY3AzhRv0Pplyg1g=; b=xOcgOTvTnCN0ETaLDtFjhaq5iiAn24nFe1u5TMjIzPoLCA3E3NBu0rSi4r94xXQn4B 4Dz16qLVb0aTq0XDtaL5eiyWQLjv3GsRyXGZZ8QZmHjEWXkFfVmECu6lvor5yzxM8wNB 29Mfyqd43ovPh+YcMCpC9aU1Z2VLn6aKOOZ2wb58T62SUIyU1x3FGHuENCHowL959u5d D5OtXpu1O8oK6RyA+3ULpR++pdnbEwyIheKgd7dVafCjKkXU+OPHZuO1r/zXEYVEhKXI ZSpHtD1WTYU3zYAq8LMPzCx5jjabM1d+ztpiJ64UdqQiK/gZhbOj5XxV20Psg8/DiUUi hSKg== X-Forwarded-Encrypted: i=1; AJvYcCUXx9+LV041C6tN8E4FxBE0IbXIRYXf9o4Iy2pLHm6jiP8elX7LFKpLaboZiyTphSLtLl0CxoLVVJw=@passt.top X-Gm-Message-State: AOJu0YzxoEUdzTd704+DDkrvaiYcbaDxEWfcF9f1hsgjqG5qIhjzvQOi gn87/oaivahsk5TBzunNOsj3Am0NdKc5OGaH6kWj41sg5cSCiLywbNJQ9T8rz0iclnqvdVyzm1m /L3pTC3jNR7qD+kx4qann1L7LeMy3w92N3KAxhKWThW+3yobuzB9g8gPBymRAhLOckp+Odk0imS v15QuIrFbwba+uHoN+IUI9IpTmwj6L X-Gm-Gg: AY/fxX6ExzqEljwhCFMlc5aM4GHcXRt9lSLVaap4HyM8PlC3TKdD7X6x6SiVpnIDoCS 4ZOBRITTumwUY3JWtogixvY3tgwZoRUZ0pZeTd67FivhF4nzZFPGGo9RzoOxL2rtmTbUV1C0b1B nX0um3v0IukaCJKcvHLx2k2wo/uMKhKHsdAy/lRT0nGSB9OWhrnSKtutJ3LcdXAaznkTV9ub/kS Tyf3sNF4MB3un52wJuxBhdrC04fGtsUEOR4wX5xAp+CzoK9K29KFKigYqAhyx8jjJ74gi1eQBgl bLHvWGvQQ4U+ X-Received: by 2002:a05:6402:3582:b0:64b:4624:7780 with SMTP id 4fb4d7f45d1cf-65097e6c0e5mr14088836a12.23.1768206031590; Mon, 12 Jan 2026 00:20:31 -0800 (PST) X-Google-Smtp-Source: AGHT+IGPP4UE+8UoP0q6x6utVwv6ywyWOj/notvjMVCuOsHH+S1qt3xoodQA45CSWXz1Ne3wm9WQ/uGmzxPQo6nDWQ8= X-Received: by 2002:a05:6402:3582:b0:64b:4624:7780 with SMTP id 4fb4d7f45d1cf-65097e6c0e5mr14088816a12.23.1768206031130; Mon, 12 Jan 2026 00:20:31 -0800 (PST) MIME-Version: 1.0 References: <20251229095558.918055-1-yuhuang@redhat.com> <20260105221056.71e7ff8b@elisabeth> <337b7401-7794-4538-80b0-7ddae66daae7@redhat.com> <20260110191202.027b7f95@elisabeth> In-Reply-To: <20260110191202.027b7f95@elisabeth> From: Yumei Huang Date: Mon, 12 Jan 2026 16:20:20 +0800 X-Gm-Features: AZwV_QhGHrTuHWXXZTONdbArmRN-_6wh_AaOm_553aq4bIkMkYhfBEkY3iQRwqM Message-ID: Subject: Re: [PATCH] conf, pasta: Add --no-tap option To: Stefano Brivio X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 9nAOGuFEly67TeJsois2KAI6BWMxopWE_8W-3yx6x9w_1768206032 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: 2WOCVUIOHITE72XF7YKL7CGRHY7XEK5Z X-Message-ID-Hash: 2WOCVUIOHITE72XF7YKL7CGRHY7XEK5Z X-MailFrom: yuhuang@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Paul Holzinger , passt-dev@passt.top, david@gibson.dropbear.id.au, Jon Maloy X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Sun, Jan 11, 2026 at 2:12=E2=80=AFAM Stefano Brivio = wrote: > > [Cc'ing Jon for awareness around the part about netlink monitor and > capabilities, four paragraphs down] > > On Wed, 7 Jan 2026 16:20:18 +0100 > Paul Holzinger wrote: > > > On 05/01/2026 22:10, Stefano Brivio wrote: > > > On Mon, 5 Jan 2026 14:48:15 +0100 > > > Paul Holzinger wrote: > > > > > >> Sorry I was out for a while so I didn't had time to clarify on the b= ug > > >> before. > > >> > > >> On 29/12/2025 10:55, Yumei Huang wrote: > > >>> This patch introduces a mode where we only forward loopback connect= ions > > >>> and traffic between two namespaces (via the loopback interface, 'lo= '), > > >>> without a tap device. > > >>> > > >>> With this, podman can support forwarding ::1 in custom networks whe= n using > > >>> rootlesskit for forwarding ports. > > >> I guess I didn't really communicate my requirements well. > > > I guess it's more likely that you actually did, but I mixed up the > > > association between requirements and use cases, sorry for that. > > > > > > In any case, good that we need this anyway, just for another use case= . > > > :) > > > > > >> When we use > > >> rootlessport (rootlesskit) today for custom networks we only do so a= s > > >> rootless user and it forwards ::1 (by possibly mapping this to v4 in= side > > >> the container) fine. > > > So, wait a moment, is my comment at: > > > > > > https://github.com/containers/podman/issues/14491#issuecomment-289= 8191772 > > > > > > actually wrong? I don't have time right now to test that but from use= r > > > reports and some vague memory I thought ::1 forwarding wouldn't work > > > with custom networks regardless of root or rootless, because > > > rootlesskit didn't handle that anyway. > > > > yes, rootlesskit handles ipv6 just fine, it is just that our > > rootlessport code remaps that to v4 inside the container. > > Actually, at a glance, I don't think that this could be fixed entirely > in the rootlessport implementation, as rootlesskit doesn't seem to look > at the destination address of the original connection at all. > > > >> My main point for this feature was using as root (requires further > > >> changes to allow pasta running as root). > > > ...which should be entirely on Podman side and it's still on my plate= , > > > by the way: > > > > > > https://github.com/containers/podman/issues/17840 > > > https://pad.passt.top/p/Features_2025#L40 > > > > I don't see how this can be fixed on the podman side, the network > > namespace of a rootful container (not userns=3Dauto) is owned by the ro= ot > > user. If you configure something in there you must have real > > CAP_NET_ADMIN from the host init userns. So pasta must not drop this > > privilege before configuring the netns. > > Oops, right. My starting point was this change, which is actually > trivial (at least as a test) and something I already tried out, but > then I hit a number of issues in Podman I never really figured out. > > So yes, it takes one change in pasta, but the substantial part left for > me to figure out is why Podman didn't just work with it. It's not > necessarily complicated, I spent just a couple of hours on it, so maybe > there's something simple I missed. > > > And even then with the future > > netlink monitor work we would need to keep that privilege level to > > modify the netns even during runtime? > > This just reminded me that, somewhat surprisingly, for netlink > operations, the check on capabilities is not just performed on the > process creating the socket when the socket is created, but also later > *on the sender of the message*. > > This is inconsistent with other operations on other types of sockets > where the whole context is checked and assigned at the time of the > creation, and was introduced because of a specific behaviour of Zebra > (the routing daemon) in 2014, see discussion around: > > https://lore.kernel.org/all/87d2g7d9ag.fsf_-_@x220.int.ebiederm.org/#r > > and I stumbled upon it a while ago while preparing a seitan demo > replaying nft messages for an unprivileged container: > > https://seitan.rocks/seitan/tree/demo/nft.hjson#n38 > > So, my blanket answer "we create that socket at the beginning" doesn't > apply here. > > However, assuming that this RFC patch from Jon actually works (I haven't > tested it): > > https://archives.passt.top/passt-dev/20251215015441.887736-11-jmaloy@re= dhat.com/ > > I would say we're fine with it. Well, there's still the possibility > that it doesn't work if Podman originally detached the network > namespace, I'm not sure. > > If it doesn't work, we'll need to retain more capabilities, or even > keep a cloned process around for this kind of stuff. We could also fix > that in the kernel, Zebra doesn't need that quirk anymore. > > > >> Because as root podman does > > >> port forwarding via DNAT firewall rules (i.e. custom nftables rules = we > > >> add). The kernel however never added support for DNAT on ::1 meaning > > >> clients trying to access that are not getting forwarded. The only wa= y to > > >> support this is using a user space helper. Right now this doesn't wo= rk > > >> and we do not use rootlessport for this either so I was just thinkin= g > > >> ahead because we do have these users requests who want ::1 to work a= s root. > > >> > > >> For the current rootlessport use case we also must bind all ports as > > >> given (i.e. also addresses 0.0.0.0 bind address), just forwarding > > >> loopback to loopback is not what we want or do for security reasons,= see > > >> CVE-2021-20199. And logically it would not really work to have anoth= er > > >> process bind 0.0.0.0 and this pasta helper bind lo on the same port = at > > >> the same time. > > >> > > >> The way I am thinking is bind ports as normal, add the no-tap option= and > > >> add two options to give the v4 and v6 namespace (container) side con= nect > > >> addresses so we never actually connect to lo. Then we also should ha= ve a > > >> dynamic way to update the connect addresses at runtime which is requ= ired > > >> for podman network connect/disconnect to work which changes the > > >> addresses inside the namespace, see > > >> https://github.com/containers/podman/commit/e88d8dbeae2aebd2d816f16a= 21891764163afcd4. > > >> > > >> Overall none of this is a blocker for removing rootlessport. I think= our > > >> plan was and still is to use the dynamic port forwarding logic David= is > > >> working on to replace the rootless custom network port forwarding ca= se > > >> with that. > > > Regardless of other requirements that are needed as well to support > > > forwarding ::1 for root containers (or rootless with --userns=3Dauto)= , > > > this feature by itself makes sense as it is and we'll need it as it i= s, > > > right? > > > > > > By the way we routinely get requests for this feature by pasta (and > > > Podman) users, regardless of any specific Podman integration, so I > > > think the feature is generic enough as to make sense regardless of yo= ur > > > plan for root containers. > > > > I am not sure how I would use or integrate a loopback to loopback > > forwarder in podman so I don't think we would need or can use that as i= s. > > Well, I'm not sure, I just remember that you had in mind some use cases > that could be fixed with this (and even noted them down in the > references from the ticket). > > Sorry Yumei, I should have checked more recently, as it looks like this > doesn't currently have as much priority as I thought, at least in > Podman's perspective. In any case it's definitely useful. No worries at all :) > > By the way, if it's for the root case, we'll still need it the day we > support operation when started as root. If it's to fix up IPv4 / IPv6 > loopback mapping in the rootless case, it would be usable right away. > > > I think the use case itself is still interesting and if there are end > > users asking for it sure not objections from me. I guess it could be > > interesting to expose a service without giving it access to the full > > internet and without having to deal with complicated firewall rules, > > i.e. with this we get a container that only could communicate by > > replying to the forwarded ports. > > Right, yes, it might also be one way to implement "isolated" containers > as described in https://bugs.passt.top/show_bug.cgi?id=3D139 (I still hav= e > to follow up on comments there, and that might take a while, but let me > quickly mention that it has little/nothing to do with local mode). > > -- > Stefano > --=20 Thanks, Yumei Huang