[PATCH v2 2/5] userns: don't let setns() lend CAP_SETFCAP

[Christian Brauner]

On Fri, Oct 16, 2026 at 11:05:26PM -0500, Serge Hallyn wrote:
> On Wed, Oct 14, 2026 at 08:47:47PM +0000, Josef Bacik wrote:
> > Mapping uid 0 of the parent into a user namespace requires CAP_SETFCAP,
> > because a task in such a namespace can write file capabilities that are
> > honoured in the parent.  A task that is already in the namespace has a
> > full capability set there and can't be asked any more, so
> > verify_root_map() goes by what the creator had, now ns->setfcap_level.
> > 
> > But setns() lets other tasks in, and they get the full set as well:
> > 
> >   task A: uid 0, full caps          task B: uid 0, no CAP_SETFCAP
> >   unshare(CLONE_NEWUSER)
> >                                     setns(A's user ns)
> >                                       allowed, euid == ns->owner
> >                                     write "0 0 1" to /proc/self/uid_map
> >                                       ns->setfcap_level is A's -> allowed
> > 
> > or, if A's namespace maps uid 0 already, B sets security.capability on a
> > file.  Either way B ends up with file capabilities that are honoured in
> > the initial namespace, which it could not have written there, nor in a
> > namespace it created itself.
> > 
> > Refuse setns() into a user namespace unless the joiner's CAP_SETFCAP
> > reaches at least as far up as the namespace's setfcap_level.  Then every
> > task in a namespace is entitled to what its setfcap_level says, and the
> > checks on the way to file capabilities can go by the namespace.  This
> > has to apply to every user namespace, also to those that don't map the
> > parent's uid 0: through an idmapped mount, a root user that only exists
> > in the namespace can be stored as the parent's.
> 
> Can you please explain what you mean by this about idmapped mounts?
> 
> It feels like something we should not be trying to protect against.  The
> mere fact that an admin can create an id wormhole with an id mapped
> mount where uid 100000 is mapped to 0 on the host, does not mean that
> everyone who wants to setns to a namespace which maps uid 100000 should
> require CAP_SETFCAP, imo.  It just means the admin should be careful.

Yep. And it is in active use and was an explicit design requirement.
Again, Incus and LXD both do this on purpose to avoid shifting an
uid/gid and ensure that access to /var/lib/containers or whatever is
restricted.