[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