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