Re: [PATCH 0/5] capabilities: close the ways around the CAP_SETFCAP rule for uid 0

On Fri, Oct 09, 2026 at 09:41:59AM +0200, Christian Brauner wrote:

On Thu, Oct 08, 2026 at 11:13:57AM -0500, Serge Hallyn wrote:

quoted

Yeah, that's what I was thinking.  Or even stricter: ensure that to join
any user namespace, a process must have a superset of the namespace
creator's capabilities.

I think both are fine and I like this proposal.

One correction to what I wrote: the weaker version isn't enough.  A
namespace that maps "0 100000 1000" doesn't map the parent's uid 0, so
it passes that check.  But with an idmapped mount that maps fs 0 to
100000, a task that joined it can write fscaps that are stored with
rootid 0 and honoured by the host.  We test that flow.  So it has to be
Serge's stricter version.

I think that this is an acceptable restriction. Mapping uid 0 to 0 and
dropping caps is borderline useless.

That makes the restriction wider than the 0 to 0 case.  A root task
without CAP_SETFCAP couldn't join an ordinary "0 100000" container
either.

setns() also only covers the routes that go through it.  These don't,
and need their own checks either way:

- writing through a uid_map fd opened by a task with CAP_SETFCAP
- ptrace and pidfd_getfd of an entitled task from outside
- a task without CAP_SETFCAP creating its own namespace, which a
  privileged task then maps "0 0 1" for

So v2 would be a level on the namespace computed at create time, the
strict setns() check, and the checks at the map write, setxattr and
ptrace reading the namespace's level instead of the cred's.  If that
sounds right I'll put it together.

Thanks,
Josef