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 > >