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=hN3HGLQY; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTPS id 7BA055A004E for ; Mon, 05 Jan 2026 22:11:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1767647467; 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=t/XcbuS22CBX8wc60SCa3CZehhVMeZu6o8H7qJBe3Xk=; b=hN3HGLQYGjjr7lukDLRGpa4z4gncm82J10E74AXSTEqEAmvqp+fH+1enmPE2H23WGrRv51 7cUMRMsqWY54VprQZohTK/uvvmwbjyvm6W0f/764/fJyvNDkenefJ7p8Sp6spHlMcOptxo OaJ9rq4D+kbeHW/nsWNgV8vdNJWO2sY= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-85-We8mpCiDPSCv2UriqWatXQ-1; Mon, 05 Jan 2026 16:11:06 -0500 X-MC-Unique: We8mpCiDPSCv2UriqWatXQ-1 X-Mimecast-MFC-AGG-ID: We8mpCiDPSCv2UriqWatXQ_1767647465 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-430fb8d41acso143250f8f.1 for ; Mon, 05 Jan 2026 13:11:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767647464; x=1768252264; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=t/XcbuS22CBX8wc60SCa3CZehhVMeZu6o8H7qJBe3Xk=; b=slukK3C6H6Yl7rc9VPxyhMt0402KweudTeDgiTg1JGGVgQYz6nilN9VyfYudtBFvLY /Yr4PdG84r7KALpRYIX3QPOGdSdrvE/UqoX8MuVL2JN9yW9blqS6ITbekM6Mo9t4LlwG cjV/uNt/ZLrwwD0QGQiEIiZGoDP/wg8D805jOJpe0dCOASEOYBUnCAmug3dnrxGluEJJ hb9gugYJhgnY7L2fpnB5FOOh3v+epAL+WjQltNC2p3ZS5pUOwIll61fihVxsiaaTYRs2 hWZPom/4zzycPAqnms59crzpvEXloG5NEWyng/PtC8AVDqKlpCKWNgiCWJtuWylzbNDs sCWw== X-Forwarded-Encrypted: i=1; AJvYcCU71dkw37qA1ZrgFxZLbmm1s7ehuKG+k5B70D2MqbSCNSmxPkEz8cmk5iQPskUGibLsKEVOfclTGhY=@passt.top X-Gm-Message-State: AOJu0Yw0aHHWB6tPzxr5efA9H5IX2kOHHsdhsDuV9TP/HKVpxeZE3SVD M/04XWSW+t/JKwtq4S5y1HWGOUmkklYr0Wf8x9fSAqvlpsrcZFiL7P7pbT22xH/64m5YTKeflMh dx7kY0fWpHBkDMqMHPvlwDZaf4R5hdCM5n9ylwoF9zHK3k53QDrvUCkbmQ8R1/w== X-Gm-Gg: AY/fxX690yvLC4UgqJ1nRu0MVmhzt5UtPeyxGlcedtG2mfk1ERchaogmHFtJrJLiyY0 1XW5nHMlfsnsWAM6WtcghFOK4h5DO5/Uy/SPc7vF8mhAeKki2a3PKvfEsxaLwVapV5W6ZzcPa7F 9k3/RZ6R6SIHZ2OB/62hws6C5o01COAWF49myUcqcPGWPO3/Lz+Lbi0bh/VO14mZA5PgRP7zkCA 5xrqd+X5S7nHVBZ9DokzpjygxvFLsTcvDv3poQVwrU9R2I0Wt+MnHiymS/CozU6cNYPFSS9Xepi FT1ycPTQVHXPbUE089XdqrxRAkJ71l3oP8osR1bNXsFRMuLS+LUvpTaU1VZfHNjqY5GnQGCh8B2 iIzZoayIbvRfjlNjvus/n X-Received: by 2002:a05:6000:400d:b0:430:f58d:40e5 with SMTP id ffacd0b85a97d-432bca50a4dmr1176376f8f.30.1767647459284; Mon, 05 Jan 2026 13:10:59 -0800 (PST) X-Google-Smtp-Source: AGHT+IFR7uqhrtn3WA5lZE3PBlZ1LmelOPrEfkfjzGTggTWSPvj7T/8dpX6qeQgIr9YRsmmkIccpXg== X-Received: by 2002:a05:6000:400d:b0:430:f58d:40e5 with SMTP id ffacd0b85a97d-432bca50a4dmr1176355f8f.30.1767647458740; Mon, 05 Jan 2026 13:10:58 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5ff319sm508853f8f.43.2026.01.05.13.10.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Jan 2026 13:10:57 -0800 (PST) Date: Mon, 5 Jan 2026 22:10:56 +0100 From: Stefano Brivio To: Paul Holzinger Subject: Re: [PATCH] conf, pasta: Add --no-tap option Message-ID: <20260105221056.71e7ff8b@elisabeth> In-Reply-To: References: <20251229095558.918055-1-yuhuang@redhat.com> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: X9k56o_ONNaWqXU_1SU0qEo5NatFAPUg1EyR8lsbMxQ_1767647465 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: P4BG4T33NSRCOA2VBK35LVXOX37BL4FT X-Message-ID-Hash: P4BG4T33NSRCOA2VBK35LVXOX37BL4FT X-MailFrom: sbrivio@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: Yumei Huang , passt-dev@passt.top, david@gibson.dropbear.id.au 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 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 bug > before. > > On 29/12/2025 10:55, Yumei Huang wrote: > > This patch introduces a mode where we only forward loopback connections > > and traffic between two namespaces (via the loopback interface, 'lo'), > > without a tap device. > > > > With this, podman can support forwarding ::1 in custom networks when 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 as > rootless user and it forwards ::1 (by possibly mapping this to v4 inside > the container) fine. So, wait a moment, is my comment at: https://github.com/containers/podman/issues/14491#issuecomment-2898191772 actually wrong? I don't have time right now to test that but from user 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. > 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 > 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 way to > support this is using a user space helper. Right now this doesn't work > and we do not use rootlessport for this either so I was just thinking > ahead because we do have these users requests who want ::1 to work as 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 another > 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 connect > addresses so we never actually connect to lo. Then we also should have a > dynamic way to update the connect addresses at runtime which is required > for podman network connect/disconnect to work which changes the > addresses inside the namespace, see > https://github.com/containers/podman/commit/e88d8dbeae2aebd2d816f16a21891764163afcd4. > > 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 case > with that. Regardless of other requirements that are needed as well to support forwarding ::1 for root containers (or rootless with --userns=auto), this feature by itself makes sense as it is and we'll need it as it is, 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 your plan for root containers. -- Stefano