From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTP id 9FA645A0276 for ; Mon, 12 Feb 2024 17:57:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1707757032; 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=wJ7vsRxq+YJqfcTWYeVyiwpuCSz2Woq4jHEHI5VTM3U=; b=KYLaIr1BzjTMjw88ZALSyCnECLxTNFcq1Ax3YFVgBCCVeAhh7JnZIaFoexSWuC/28uZIrO k/Ee6JwS0J4GU1SOLnpF2dfVoujiP0PSESf9V4F3QWYLrydBP3+frX7jHlK1upLufpMLWg TU8vo/zQjKySmBItLFTtP87Ihq5hONg= Received: from mail-ej1-f70.google.com (mail-ej1-f70.google.com [209.85.218.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-333-FloJ0ITuMUCACiuTSwx5nw-1; Mon, 12 Feb 2024 11:57:11 -0500 X-MC-Unique: FloJ0ITuMUCACiuTSwx5nw-1 Received: by mail-ej1-f70.google.com with SMTP id a640c23a62f3a-a30f9374db7so442048166b.0 for ; Mon, 12 Feb 2024 08:57:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707757029; x=1708361829; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=j2kSQdUo8xlKdAj4HnGVcA4cw3gCZ8gu1HkPbHSNGrA=; b=Y93jH6GMpg7ReQ2W5iiCXyserr16MavUccK00EM1Wws1n2DcAIafh+hszd9BcI6PBK CzV6K4QO5EZWdgPIC5c5hbaLGV4QBmc2hHipXxd1KYoPYSv0ZEb9iKcBkthGgN7cxZ8p +OibO7t4H8fzzmvjHJmsvoVop92oyHh7nqAAlBHj+WumqJVxHNBo+DqDpZ86uNl8bfiz c6kWGZqoT+NUHYVleYMWvat++otMuHTJ2y8LpjMSKmXwU309ERqidzUu8UY/P2C/n8d/ K0lxnKSdpLF0NsVSFAfYWUOQPU1yBO54eDN6cP0ZaLP3OtluE9jZ0Qon4ndmiuY92PgE gr9A== X-Gm-Message-State: AOJu0YzrRAvrZtBAueeCez9NA0Xl1YuXge1k328tpbYL9ImhGq3E6S/+ u1x2zG+3RteuNBmCMmd6zbksCHacJW30si6irZ5pY50nxLkx2JP04Bdl67ym9XegrhXwKSgBuWN j2yc3Zd1gnK3aQJJY1U3nprl2LN0FajcV6UIG5tUfEGkKxx+GOnz0ipFyXiSX0PFwApuVPKboAD n+ZfaIpAm6FPd2tjuqw8451Ge6qWJHhkbFdUM= X-Received: by 2002:a17:907:174f:b0:a38:3eb1:40a1 with SMTP id lf15-20020a170907174f00b00a383eb140a1mr53192ejc.26.1707757029423; Mon, 12 Feb 2024 08:57:09 -0800 (PST) X-Google-Smtp-Source: AGHT+IF9hfPWcBowWpouLrRUpI5uiKUUiQP9jIM8aY9F1XLo6Z2/em/73pGI0S8sR6KOXN/mvV/RGQ== X-Received: by 2002:a17:907:174f:b0:a38:3eb1:40a1 with SMTP id lf15-20020a170907174f00b00a383eb140a1mr53173ejc.26.1707757029015; Mon, 12 Feb 2024 08:57:09 -0800 (PST) Received: from maya.cloud.tilaa.com (maya.cloud.tilaa.com. [164.138.29.33]) by smtp.gmail.com with ESMTPSA id l13-20020a170906a40d00b00a3be3b27d0bsm380532ejz.49.2024.02.12.08.57.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Feb 2024 08:57:08 -0800 (PST) Date: Mon, 12 Feb 2024 17:56:32 +0100 From: Stefano Brivio To: Paul Holzinger Subject: Re: pasta does not correctly handle bind errors with port ranges Message-ID: <20240212175632.5ec08dd6@elisabeth> In-Reply-To: <6f64c0df-3b96-453a-a3a7-8a3fb2c1d70c@redhat.com> References: <20240209220939.2f477a76@elisabeth> <20240212151331.277ef9fd@elisabeth> <6f64c0df-3b96-453a-a3a7-8a3fb2c1d70c@redhat.com> Organization: Red Hat X-Mailer: Claws Mail 4.1.1 (GTK 3.24.36; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: 2AJIE3ENSTSZK4XPCRJM4SYILF7HLFWK X-Message-ID-Hash: 2AJIE3ENSTSZK4XPCRJM4SYILF7HLFWK 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: passt-dev@passt.top 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, 12 Feb 2024 15:43:00 +0100 Paul Holzinger wrote: > On 12/02/2024 15:13, Stefano Brivio wrote: > > On Mon, 12 Feb 2024 12:45:00 +0100 > > Paul Holzinger wrote: > > =20 > >> Hi Stefano, > >> > >> On 09/02/2024 22:09, Stefano Brivio wrote: =20 > >>> Hi Paul, > >>> > >>> On Fri, 9 Feb 2024 17:57:05 +0100 > >>> Paul Holzinger wrote: > >>> =20 > >>>> Hi all, > >>>> I found some issues with the pasta port binding logic, it does not > >>>> correctly handle errors when trying to bind a port range. > >>>> Let's first bind a port so we can force an error condition it: > >>>> $ nc -l -p 8080 & > >>>> $ pasta -t 8080=C2=A0 true > >>>> Failed to bind any port for '-t 8080', exiting <-- fails as expected > >>>> $ pasta -t 8081 -t 8080=C2=A0 true > >>>> Failed to bind any port for '-t 8080', exiting <-- here it also fail= s > >>>> correctly > >>>> $ pasta -t 8080-8081=C2=A0 true > >>>> <-- no error even though pasta could not bind 8080 =20 > >>> This is actually intended: it only fails if it can't bind *any* port = in > >>> a given range, so that users don't have to explicitly exclude ports > >>> from ranges in case some are already taken, knowingly or not. That's > >>> why the error message says "any port". =20 > >> Ok but this results in a very inconsistent behavior. I argue this is n= ot > >> what a normal user expects at all. =20 > > This really depends on the user. The main usage behind the current > > behaviour is the "all" forwarding mode, as originally designed for > > KubeVirt, now available via libvirt in two forms: -t all / -u all, or > > giving excluded ranges only (from the man page: "Specifying excluded > > ranges only implies that all other ports are forwarded."). > > > > At least this part, specifically, is an established behaviour and we > > can't break it. > > > > But that's not a substantial conflict with what you're asking for > > Podman: we can keep this behaviour only if the user asks to forward > > (almost) "all" the ports (in whatever way). And Podman never asks for > > that, and probably never will. > > =20 > >> It is not even documented in the man page. =20 > > Right, yes, we'll need to describe it. > > =20 > >>> For two ports it probably makes no sense, but for larger ranges > >>> excluding dozens of ports can get quite annoying for the user. And > >>> warnings on failed bind() calls could get quite noisy, too. =20 > >> At the same time this can result in a lot of unexpected problems for > >> users as it just hides potential problems, assuming 8001-9000 are > >> already in use then -t 8000-9000 would work and then one might > >> reasonably expect that if they connect to any of the given ports they > >> talk to the pasta namespace and not something else, this could be a > >> security concern. I would say in such case yes I want to see a logged > >> error for each individual port. =20 > > I see, but again, if just port 8005 is not available, you might say > > that having pasta succeed is a security concern because somebody can > > "steal" the port, or that having pasta fail is a nuisance because the > > user probably just wanted to forward the remaining 1000 ports, and > > graceful degradation would be desirable instead. > > > > It's pretty impossible to draw a line in a different way that's not > > considered inconsistent or inconvenient by some. So: =20 > > Yeah I understand that, I guess I just am missing the use case of=20 > forwarding large port ranges in general as I don't understand how it is= =20 > used in practice. As an application inside the VM/container that just=20 > binds a port it has no knowledge whenever passt/pasta forwarded the port= =20 > so if it happens to use one that was skipped because it was already used= =20 > on the host it just won't get external connections. The "host" could be a very controlled environment, such as a dedicated network namespace, say a Kubernetes pod. One example I have fresh in mind, KubeVirt with Istio: https://kubevirt.io/user-guide/virtual_machines/istio_service_mesh/ Service meshes are usually implemented by / designed for containers. If you move some parts (implementing a number of servers) to a virtual machine, they don't expect to get any connection to the ports that are normally taken on the host, but anything else is legitimate. > I guess the answer for that is user error/problem. In some sense, yes. Mind that we have automatic and somewhat abstracted users, too, which is not so much the focus for Podman. > >>> If it's a problem for Podman, I can think of two solutions. One would > >>> be an option such as --strict-bind or suchlike (better names warmly > >>> welcome). =20 > >> It is a big problem for podman as it does not do what users want us to > >> do. Also, because podman is smart enough to combine several ports into > >> ranges internally for performance reasons, something like -p 80:80 -p > >> 81:81 is always a range for podman thus there is no way for podman use= rs > >> to avoid hitting this problem. An opt-in option works for me but then = we > >> need to bump the minimum pasta requirement version for podman which is= a > >> bit annoying as I would need to wait until the versions lands in our C= I. =20 > > ...would probing for the option be a possibility? That is, run 'pasta > > --strict-bind', and if it fails, log a warning and continue without the > > option. > > > > If that's too cumbersome, then I would skip the new option and change > > it to simply fail if we can't bind a single port (and report the single > > error right away), unless the user requests to forward "almost all" the > > ports, in which case we could probably warn() with a list of the ports > > that we couldn't bind. =20 >=20 > I am fine with an opt in option, it just means that I will need to wait= =20 > a bit until the passt package landed in fedora and our CI images before= =20 > I can implement it. Retrying without that option is a good idea but I=20 > rather just make a clean requirement of version xxx to not complicate=20 > the podman code. We are in process of finalizing Podman 5.0 right now so= =20 > if such option could be implemented within the next 2-3 weeks that would= =20 > be great and I can add a note the we require passt version XXX now as=20 > part of 5.0 and make it the packagers responsibility to provide that. Okay, great. I'll send a patch in a bit. --=20 Stefano