From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=none (p=none dis=none) header.from=gibson.dropbear.id.au Authentication-Results: passt.top; dkim=pass (2048-bit key; secure) header.d=gibson.dropbear.id.au header.i=@gibson.dropbear.id.au header.a=rsa-sha256 header.s=202602 header.b=iuzsk8dy; dkim-atps=neutral Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id 8E8EE5A026D for ; Mon, 30 Mar 2026 03:09:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202602; t=1774832956; bh=WnKwSNj5z2qjg/CY2ibAGA0yvtFTNQsaaO4bSmHh5tE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=iuzsk8dy4GX/xHJfLpFCugvletRVu1w9xo4QCvbi2yfws8+vtjIqXN7YzvDprc4QG oPmnSsFsECgUPx88MIRZLrDs9JknSXBcFHkhB7Uk0IwNF7ILCHOifTXQNCvrLyESHE DHwtvN9MvxzZS++gYYlpl7ZF8L4tD0nkZ2QTGs0EX+OhzyTHc5CMtr8HN3rieffxOS NmB/RtDt7LQnJx6nWQzb25p6aj9RynyNz5iri1YyNI7GkclCH5SdoOf/TQfPy7/437 +NOXTVNx9m5RB3GLX3M/7sc5OUAJX1kCqSIeRsGTxT7hqfAc+9S+0tx+ANli3bRkwN GadsmEiKndH3A== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4fkY701q75z4wqN; Mon, 30 Mar 2026 12:09:16 +1100 (AEDT) Date: Mon, 30 Mar 2026 12:08:58 +1100 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH 15/18] pif: Limit pif names to IFNAMSIZ (16) bytes Message-ID: References: <20260327043430.1785787-1-david@gibson.dropbear.id.au> <20260327043430.1785787-16-david@gibson.dropbear.id.au> <20260329140226.18e910fb@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="IeZ5w73PtANOn6ML" Content-Disposition: inline In-Reply-To: <20260329140226.18e910fb@elisabeth> Message-ID-Hash: JVSG7HTC63VZQDWN42B66VORQMZLONC4 X-Message-ID-Hash: JVSG7HTC63VZQDWN42B66VORQMZLONC4 X-MailFrom: dgibson@gandalf.ozlabs.org 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: --IeZ5w73PtANOn6ML Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 29, 2026 at 02:02:27PM +0200, Stefano Brivio wrote: > On Fri, 27 Mar 2026 15:34:27 +1100 > David Gibson wrote: >=20 > > All current pif names are quite short, and we expect them to remain sho= rt > > when/if we allow arbitrary pifs. However, because of the structure of > > the current code we don't enforce any limit on the length. > >=20 > > This will become more important with dynamic configuration updates, so > > start enforcing a length limit. Specifically we allow pif names to be = up > > to IFNAMSIZ bytes, including the terminating \0. This is semi-arbitrar= y - > > there's no particular reason we have to use the same length limit as > > kernel netif names. However, when we do allow arbitrary pifs, we expect > > that we might support a similar number to the number of kernel interfac= es. > > It might make sense to use names matching kernel interface names in that > > future. So, re-use IFNAMSIZ to avoid surprise. >=20 > And what if... we used 128 instead, which is reasonably longer than > UNIX_PATH_MAX (108, which despite the application usage in POSIX 2024.1: > https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/sys_un.h.html > is still commonly used a path length limit, also by passt itself)? Well, certainly we could make pif names longer... > At that point we could embed UNIX domain socket paths as PIF name > (possibly with some additional specifier) which _might_ be useful to > forward UNIX sockets in the https://bugs.passt.top/show_bug.cgi?id=3D200 > sense. =2E..but I don't think that rationale is compelling. The unix socket path would be the equivalent of IP+port, not the pif. I don't see how embedding a unix path in the pif would be useful. > It's not the only way to implement it, but perhaps it's one possibility > that might make sense for what we know now? What do you think? >=20 > It also has the advantage of being sufficiently longer than IFNAMSIZ, > so that should we ever need to have stuff like "container_A:eth0" in a > PIF name, we could have it as well. That's a more convincing case. Ok, I'll expand the pif name size for the next spin. --=20 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 --IeZ5w73PtANOn6ML Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmnJzRgACgkQzQJF27ox 2GdV+Q//bj+aFmy6xu3YGXZWb1r3EEtk3qC1gVYVC9bzCpGncF6VFsBEivoUhBnp eS4afBd/7KOtvw4JDRveLE/fKwWRUR3SRrDohuVKkjyecEK9MOhcp85bYJMt98fc mRIyzhSvaoR1iQAn4M/3B2VdIfeu0RODIo7QLcQscKOPhBzmQBhY6KZOPYbhfeQS wNvr/VNO7ERGVyZsOYQGtAYz2POKCqgngyIOAYxGdkLzECDTBBPcbPGB8LdEjyRr BF4amvZjhxU3QCU6bpIwS25xiLt5cGAjUkrhUeqe4JAQM2VxsQ9w9pI5MT92+qkf elmvNoZ8uNLsgaBAdPEHKIzxuq6yPdTdjJIDj8tMfIF0bUY5wc+J79Evpk8ZFO2w dvj2rnhRmXn4LIspFqRoOBTfpG8Cij2yCO6UXxbz9+6gBcGZ8xmWQzwW+LPKh4wm saKIwIyKyzLF847nVUwYeJaScf+Jsg4qTCgC8NjQ1q7ncWplqHYVqJgtHmr0ULaX U96UxxhTcSS8QzXRc5TR4SAkmTzYN1z1Q0fKDCtli3hZQ/5pA2Y5gpxMVRP5/U7T yJJ5Uj/leeznpwqxaZhrxX26Qyfa6UpGCFoR2gxmBt0aUCNVrMGUr8fg1RYRW01j 9adtNY+4I8ByfjPuk1GIIbHnlOgsmFRIEEYqIC3B9xhqU1XGsDs= =TFTk -----END PGP SIGNATURE----- --IeZ5w73PtANOn6ML--