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 E7AA35A0275 for ; Mon, 12 Feb 2024 15:14:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1707747252; 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=C5k4HTM89yNBs27UqTknXWOXFeJs7SiWnhy1s1Xrb0Q=; b=Vk9onxuu1ENqrZO5L4iRmlfE32xSwaLJbnkhfRWn0GiWMOW9ciXMhBduWGl7SO60FYzSAS BtkK0Y4XjzgCDQ4g2IzCeQm/F+P0kwclsAboS9knrL7Xw+NTVexBpiuWjKBQ+LzAIj+SdO qXnmOZOeRNy3AbMge++HEiZS3qbMF3g= Received: from mail-ed1-f69.google.com (mail-ed1-f69.google.com [209.85.208.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-103-lGtoUz5TOHeZ0SP76xyctg-1; Mon, 12 Feb 2024 09:14:11 -0500 X-MC-Unique: lGtoUz5TOHeZ0SP76xyctg-1 Received: by mail-ed1-f69.google.com with SMTP id 4fb4d7f45d1cf-5600db7aa23so1869820a12.1 for ; Mon, 12 Feb 2024 06:14:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707747249; x=1708352049; 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=mjetoNLNAR28pAbsGUfZgbXklkLWOt1Kia4FET8GDrk=; b=NnhtSnU0Pl8zyoZLEUaFfRwhRpYVjpsLAsOSEFoSPCN+ff+Iq0Lw8bfreV6xlpQ9gD JjuzrUHPXP5c1geXMs6MILUWBl3mLKQGJ6aKG/tx1qWkWiZ/lZjFfbKiwXDh3HPZWflB 1bN94bzAAiL1+ghWYv4vQjHq/L9tv2vqkn/XE86JaYeEu+tQKfbkbys39zhBzugJJIPe Q0D/LWExos982XuudRStY1T2vInKL7j0csPv8qSslzPy2JU8ONkVqI4kpG2fAqcpsDvy GVdusq+NbtjDajoeUM/ilYGr9Dg2gXGPx7adZG2TJ6+ds7C1WHmKkIGnVesk4Lg+X8G2 s00Q== X-Gm-Message-State: AOJu0YzQJhIEJQBL2D5dP3P9qvNoc9SEOlMzKL7QJxrY0yH3GvEGXau0 j2nRmtR+qYo/eoghex07nY6ddBjbhGruwDFykiIv4WIdYWtmWrAptzbHuFWT737XbhyfI88v3ma 3VPLY06GpJmhF3S7gu1KCG+a5lResyTk2sKP0VyrF0G3Sz8LuBjNXrer0t+0IBYsx/UleXd0gOk fujkx7C4uApO/UfEQefjdjQVEyea/cr6CQ5G4= X-Received: by 2002:a17:906:4812:b0:a3b:b795:1b79 with SMTP id w18-20020a170906481200b00a3bb7951b79mr4677601ejq.37.1707747249143; Mon, 12 Feb 2024 06:14:09 -0800 (PST) X-Google-Smtp-Source: AGHT+IEdWkBgl8VbpUeT5jS4nvsstg4H5XB524XHSsuFpTbPHOGPhi79v21wo9pcMXdkuHll5LVDKA== X-Received: by 2002:a17:906:4812:b0:a3b:b795:1b79 with SMTP id w18-20020a170906481200b00a3bb7951b79mr4677573ejq.37.1707747248636; Mon, 12 Feb 2024 06:14:08 -0800 (PST) Received: from maya.cloud.tilaa.com (maya.cloud.tilaa.com. [164.138.29.33]) by smtp.gmail.com with ESMTPSA id a6-20020a1709065f8600b00a370a76d3a0sm245833eju.123.2024.02.12.06.14.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Feb 2024 06:14:07 -0800 (PST) Date: Mon, 12 Feb 2024 15:13:31 +0100 From: Stefano Brivio To: Paul Holzinger Subject: Re: pasta does not correctly handle bind errors with port ranges Message-ID: <20240212151331.277ef9fd@elisabeth> In-Reply-To: References: <20240209220939.2f477a76@elisabeth> 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: OD67FD4ZK2EFEU74RFRRSM3DMODZEGML X-Message-ID-Hash: OD67FD4ZK2EFEU74RFRRSM3DMODZEGML 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 12:45:00 +0100 Paul Holzinger wrote: > Hi Stefano, >=20 > On 09/02/2024 22:09, Stefano Brivio wrote: > > 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 fails > >> 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 not= =20 > what a normal user expects at all. 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. > It is not even documented in the man page. Right, yes, we'll need to describe it. > > 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=20 > users as it just hides potential problems, assuming 8001-9000 are=20 > already in use then -t 8000-9000 would work and then one might=20 > reasonably expect that if they connect to any of the given ports they=20 > talk to the pasta namespace and not something else, this could be a=20 > security concern. I would say in such case yes I want to see a logged=20 > error for each individual port. 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: > > 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). > > It is a big problem for podman as it does not do what users want us to=20 > do. Also, because podman is smart enough to combine several ports into=20 > ranges internally for performance reasons, something like -p 80:80 -p=20 > 81:81 is always a range for podman thus there is no way for podman users= =20 > to avoid hitting this problem. An opt-in option works for me but then we= =20 > need to bump the minimum pasta requirement version for podman which is a= =20 > bit annoying as I would need to wait until the versions lands in our CI. ...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. > > Another idea would be that the back-end in Podman passes ranges as > > single ports... but then the command line might explode and that's > > not ideal for users, either. I'd rather favour the extra option. =20 > > Yeah that works but for large ranges it would not be as performant and=20 > there is the risk of hitting ARG_MAX (although I understand it is=20 > unlikely to be real problem given one would need to give millions of=20 > ports to hit it). > > =20 > >> Also besides this I find the error message less than ideal. It missing > >> the errno from the bind syscall so important context gets lost (i.e. > >> Address already in use vs Permission denied). =20 > > The problem is that we might fail to bind multiple ports, so there > > isn't necessarily a single bind() error. But if we go with > > --strict-bind, we could report the first error (including return code > > from the system call) and exit right away. =20 >=20 > I am fine with this, exit on the first error is what all our other=20 > network tools do. > But the behavior also exists for even a single port today, for reference= =20 > the error messages today: >=20 > rootlessport: >=20 > $ podman run -p 53:53 --rm quay.io/libpod/testimage:20221018 > Error: rootlessport cannot expose privileged port 53, you can add=20 > 'net.ipv4.ip_unprivileged_port_start=3D53' to /etc/sysctl.conf (currently= =20 > 1024), or choose a larger port number (>=3D 1024): listen tcp 0.0.0.0:53:= =20 > bind: permission denied > $ podman run -p 8000:8000 --network slirp4netns=C2=A0 --rm=20 > quay.io/libpod/testimage:20221018 > Error: rootlessport listen tcp 0.0.0.0:8000: bind: address already in use >=20 > pasta: >=20 > $ podman run -p 53:53 --network pasta=C2=A0 --rm=20 > quay.io/libpod/testimage:20221018 > Error: pasta failed with exit code 1: > No external routable interface for IPv6 Reading [1] below, this string is considered confusing too, even though I feel that hiding it conceptually clashes with the rationale of your very request. That is, one might argue that the user wanted IPv6 too, but it's not working, and we should tell the user. Anyway, we can change it to info() and run pasta with -q / --quiet. Would that help? > Failed to bind any port for '-t 53-53:53-53', exiting > $ podman run -p 8000:8000 --network pasta=C2=A0 --rm=20 > quay.io/libpod/testimage:20221018 > Error: pasta failed with exit code 1: > No external routable interface for IPv6 > Failed to bind any port for '-t 8000-8000:8000-8000', exiting >=20 > I think the answer of what is more helpful to users is obvious and that= =20 > isn't just my opinion[1]. Sure, I understand, especially in case of a single port. This is just the first time somebody reports that. > > Let me know if any of this would address your problem, I can write a > > patch in the next days in case (or feel free to submit one). > > [1] https://github.com/containers/podman/pull/21563#issuecomment-19370246= 42 --=20 Stefano