Re: Startup fd to avoid busywaits

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 AM 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 modified 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.

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