[PATCH 2/5] userns: don't let setns() lend the right to map uid 0

sashiko-bot at kernel.org sashiko-bot at kernel.org
Tue Oct 6 15:54:59 UTC 2026


> 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.  For a writer that already sits in the new
> namespace nothing can be read from its capability sets any more, so
> create_user_ns() records in ns->parent_could_setfcap whether the creator
> had the capability and verify_root_map() trusts that.
> 
> The flag describes the creator, but it is applied to whoever opens
> /proc/self/uid_map from inside the namespace, and setns() lets other
> tasks in:
> 
>   task A: uid 0, full caps          task B: uid 0, no CAP_SETFCAP
>   unshare(CLONE_NEWUSER)
>     ns->parent_could_setfcap = 1
>                                     setns(A's user ns)
> [ ... ]
> nesting namespaces below one of their own are not affected.
> 
> Fixes: db2e718a4798 ("capabilities: require CAP_SETFCAP to map uid 0")
> Assisted-by: LLM
> Signed-off-by: Josef Bacik <josef at toxicpanda.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261006-b4-setfcap-userns-v1-0-f47e7ed66072@toxicpanda.com?part=2




More information about the Linux-security-module-archive mailing list