From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: passt.top; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20251104 header.b=HBd6uJv2; dkim-atps=neutral Received: from mail-yx1-xb136.google.com (mail-yx1-xb136.google.com [IPv6:2607:f8b0:4864:20::b136]) by passt.top (Postfix) with ESMTPS id 1A4C85A0262 for ; Wed, 03 Jun 2026 18:38:15 +0200 (CEST) Received: by mail-yx1-xb136.google.com with SMTP id 956f58d0204a3-660ea43107fso734032d50.0 for ; Wed, 03 Jun 2026 09:38:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1780504694; cv=none; d=google.com; s=arc-20240605; b=RMtjtdS0VnTXSJj+UumpVYUkYs5Zbfv8ofjtoCYtrlikLrTE5gjr24AA0RnoNBXRlO 93RePOc3MWoBbIoAaT8CIazXEWGDExVq/ushLvdk69bZrQxYaC0rpnPFZrjYbgIL3QFC il7FOpWbw77en/FWsprATkLcA/piSOrkyOm7bwf3+6nALPK9Md14HAcq8++W2CE34Pj1 szpEz1WjmnZXtKzkkOhdHneIOkFMOSK2h6IIc7VIutfsaxd3gDA9+RAlvGbk7t/IoMZi dG4lcrL2B63DsNFdITWWznbeFIkPDdO2cP0or2rg+ANOLozzdXk202jbjpyj+10nuvIS PwxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=iNV+8pzdOK71pW9/D84vcmQRWl0/XjndiGlhLWdYfsc=; fh=mdZHNcLyJLpCqE3nk2MQc87Vm5pz6SHg+YD6s7cS9XU=; b=LzgHSRdrDhX5+xonU2p1jdVWmi3jE2Ujpk9ziIjegCAdkPoAMmfLdKqw9SvEm5PglM L9fWhk9Prd8jpz+pkYoZSfJu61RIyR8IvFGqNyVGtKOi2GZCGKfggD2DdlFqDeWeRr+Q BlxhpVxjvPkNTlcuK7VKxKFk8Uu1y7GdEMa/K+Hu/IweI0sjerQI6zCZ1W8gbIQK8z1K UO8ke03ExlPxwEFHqt3B1DP+kXZYPQfCHMgmf8UxqyYZ/ti/Gr24b7ktT/ZwESIoCnyZ gjXt6FVZpRzygbfexDY2gUzyGX5w0+7GMHi41yET1S2kdpJe4wMiYP6Gh7hRTov6NU4O rkSA==; darn=passt.top ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780504694; x=1781109494; darn=passt.top; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=iNV+8pzdOK71pW9/D84vcmQRWl0/XjndiGlhLWdYfsc=; b=HBd6uJv2dWp5AhgHhI8Rsiddi8N7VAvTD6JVzvRNsT2sqnPpkyitK0ZSwIEFEwEX5j /cEnPMLvPVCpDTgDrQxJmUMKtT4sxs2dvpTtzS4bPhkNnGfPGf6CiJhl7m7PagcB7mX1 0MjoXfnE5RgunVvqfJv/Mj1mM+0h/1pP+Ti12AIfxHiveumF95o4441R87B1shlgvKZs 7aBYIng68O8CDQCjxaOuuoBgKj/4H1PiWwcK13Z2E7UfvCwaJmoncRkna9IN0CqIYsaC mX3QOJHeApOoxyJD+Ja23SotIStmJt5+9K5hwAvdxj0J+kMLADU4Iyb4xY8dTEs7F0fN Z9aA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780504694; x=1781109494; h=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=iNV+8pzdOK71pW9/D84vcmQRWl0/XjndiGlhLWdYfsc=; b=n74BXeN7wlQM0h4eiggc5CwF9j9Jwc6i7GmuPaKY4lYxTWdRmFl5zVcFbsrNsc/Lnu mwLg9EZPj435aV6FeadFkAZVUV8igZLZjCnkRQE7N66GxAuJMh3G71oA4A0ZHSu+c/56 Pa91U2IL1I1NmDj678dwKU89FMDRq16Mbztoj1T02yf2Tr8Lfs+1k7FGLPFptWXSSC9I XcWjn83BoGTQi+s7PJsneYq2l+t4oG5YOhMLvje20iC/8apO4hF5Zx4DBDOt5C/kM+NL nahBY4n6y7wts0TJ/W+IqYa6YraAuhb7MPwOe+0ExI88vKYGyj/v3xudI8E5Pa1+kA7t g7cA== X-Forwarded-Encrypted: i=1; AFNElJ+++5GCGz6fBNu24JabV9wUQD/S5HRcHRy3ZAJrSzyGFt7CyQObrCUyQz4P/ACM9NLslrtZh1Bz3RA=@passt.top X-Gm-Message-State: AOJu0YxJ7oFFWhiQ8ux5uHUYNZ6UtuSZveIIWdbSytc5jNf+USdiIRl1 FR9BbzTTaZopdGwZSrvNn48lYDay3s8yXqETPdweCPOUM4FQn1TlafZwigQkmg2h5nxC2LXhKj0 7IsMpXrgi0Hh9Yp3XwKZzc/CSIDhfgog= X-Gm-Gg: Acq92OHWzDdpDkRSrnJTd1UmV07FdYKN9a5lhFXe0reOgI2SDACfwINCAbyJ+3ZRTBG OlO3IS+KRIn3O4xMlf7nAKN3c5/CVln6AjDip4nXsM5RDcqnDREo8+FLvTW73wp5sChSNwY70Tq gVXT5Jv/4hi1o+Yd1NYQmh/hbjMr45awsLfJt8YW7VsHZpmcSgMtxDwS7dfEFiBvO6jPePxoPuL 02Q/OQtuQBDRxs6AMZFjzdcJv3J+9g4X82YtERt3XQ/rTCujkKSWMwtF3qc7DSJNzqjivnvS9Dm U6FSXqTED4qZ7oxlGHsk0OxESLyChKqczzn+R/JSirkoAlRG8ay0 X-Received: by 2002:a05:690e:150c:b0:660:4886:922c with SMTP id 956f58d0204a3-660dbff38bfmr3206017d50.17.1780504693757; Wed, 03 Jun 2026 09:38:13 -0700 (PDT) MIME-Version: 1.0 References: <20260527213924.2586bca5@elisabeth> <20260603174519.15748f97@elisabeth> In-Reply-To: <20260603174519.15748f97@elisabeth> From: Lisanna Dettwyler Date: Wed, 3 Jun 2026 12:38:02 -0400 X-Gm-Features: AVHnY4LnGvdSp-rY9n0qxCvtIvw5jJdxHRtluLLCDf6eRDZDPaUpx3oDbfGatEs Message-ID: Subject: Re: Startup fd to avoid busywaits To: Stefano Brivio Content-Type: multipart/alternative; boundary="000000000000cad9dd06535c0ded" X-MailFrom: lisanna.dettwyler@gmail.com X-Mailman-Rule-Hits: nonmember-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation Message-ID-Hash: NQDJHCMPCG3MONXWFJWZDQMCFNQMQBMQ X-Message-ID-Hash: NQDJHCMPCG3MONXWFJWZDQMCFNQMQBMQ X-Mailman-Approved-At: Wed, 03 Jun 2026 21:22:38 +0200 CC: David Gibson , passt-dev@passt.top, Paul Holzinger 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: --000000000000cad9dd06535c0ded Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sure, I'll try against the HEAD of master and if it's still an issue I'll put together a small reproducer. Thanks, Lisanna On Wed, Jun 3, 2026 at 11:45=E2=80=AFAM Stefano Brivio = wrote: > On Wed, 3 Jun 2026 19:29:43 +1000 > David Gibson wrote: > > > On Tue, Jun 02, 2026 at 06:23:29PM -0400, Lisanna Dettwyler wrote: > > > Hi Stefano, > > > > > > Indeed it would be useful if the capability dropping could be modifie= d > or > > > moved until after the net and user namespaces were opened. I'm not th= at > > > familiar with the codebase so I'm not sure where would be the best > spot for > > > that to be moved to or what capability needs to not be dropped. > > > > We certainly could delay the capability drop, but whether it's wise is > > a different question. The longer we leave it, the greater attack > > surface we have while still privileged. > > > > Waiting until after the namespaces are opened means we've at least > > parsed the command line, which is a fair bit of code. On the other > > hand we shouldn't have opened listening network sockets yet, so we > > should have relatively little exposure to either external or guest > > traffic. > > Right, I guess that's the most fundamental distinction in deciding when > to drop capabilities or enforce whatever kind of restrictions, but the > rest is still nice to have as soon as possible, so here we would really > need to understand what the problem is (I didn't, yet). > > For example, Podman passes a pre-made network namespace (via --netns), > and we needed commit 594dce66d3bb ("isolation: keep CAP_SYS_PTRACE when > required") to be able to join it, but I really have no idea why we > could possibly need anything else to join one by PID, and it looks like > that comment about capabilities was added after that commit. > > But maybe that issue was caused by some other issue that has been solved > meanwhile? I guess that should be checked first. If it's not solved, a > small stand-alone reproducer would be helpful. > > -- > Stefano > > --000000000000cad9dd06535c0ded Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sure, I'll try against the HEAD of master and if it= 9;s still an issue I'll put together a small reproducer.

=
Thanks,
Lisanna

On Wed, Jun 3, 20= 26 at 11:45=E2=80=AFAM Stefano Brivio <sbrivio@redhat.com> wrote:
On Wed, 3 Jun 2026 19:29:43 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:

> On Tue, Jun 02, 2026 at 06:23:29PM -0400, Lisanna Dettwyler wrote:
> > Hi Stefano,
> >
> > Indeed it would be useful if the capability dropping could be mod= ified or
> > moved until after the net and user namespaces were opened. I'= m not that
> > familiar with the codebase so I'm not sure where would be the= best spot for
> > that to be moved to or what capability needs to not be dropped.= =C2=A0
>
> We certainly could delay the capability drop, but whether it's wis= e is
> a different question.=C2=A0 The longer we leave it, the greater attack=
> surface we have while still privileged.
>
> Waiting until after the namespaces are opened means we've at least=
> parsed the command line, which is a fair bit of code.=C2=A0 On the oth= er
> hand we shouldn't have opened listening network sockets yet, so we=
> should have relatively little exposure to either external or guest
> traffic.

Right, I guess that's the most fundamental distinction in deciding when=
to drop capabilities or enforce whatever kind of restrictions, but the
rest is still nice to have as soon as possible, so here we would really
need to understand what the problem is (I didn't, yet).

For example, Podman passes a pre-made network namespace (via --netns),
and we needed commit 594dce66d3bb ("isolation: keep CAP_SYS_PTRACE whe= n
required") to be able to join it, but I really have no idea why we
could possibly need anything else to join one by PID, and it looks like
that comment about capabilities was added after that commit.

But maybe that issue was caused by some other issue that has been solved meanwhile? I guess that should be checked first. If it's not solved, a<= br> small stand-alone reproducer would be helpful.

--
Stefano

--000000000000cad9dd06535c0ded--