Re: Startup fd to avoid busywaits

[Lisanna Dettwyler <lisanna.dettwyler@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2103 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2707 bytes --]