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

sashiko-bot at kernel.org sashiko-bot at kernel.org
Wed Oct 14 20:58:26 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.  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
> 
> [ ... ]
> unprivileged users joining their own namespaces, 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/20261014-b4-setfcap-userns-v2-0-fac4d19281d7@toxicpanda.com?part=2




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