[PATCH 3/5] userns: check the writer too before mapping uid 0

sashiko-bot at kernel.org sashiko-bot at kernel.org
Tue Oct 6 15:52:55 UTC 2026


> verify_root_map() only looks at file->f_cred.  For every other privileged
> id mapping new_idmap_permitted() wants the capability from the opener of
> the map file and from the task that calls write(), but a map that consists
> of the single line "0 0 1" takes the unprivileged branch, where only the
> opener's euid counts.  So an open uid_map file is a token for mapping
> uid 0:
> 
>   task A: uid 0, full caps          task B: uid 0, no CAP_SETFCAP
>   fd = open("/proc/<pid>/uid_map")
>   B gets fd by inheritance
>   or SCM_RIGHTS
>                                     write(fd, "0 0 1")
>                                       opener had CAP_SETFCAP -> allowed
> 
> B set up a mapping that it is not allowed to set up.
> 
> Apply to the writer what is applied to the opener: in the namespace that
> is being mapped, its credentials must have come in with CAP_SETFCAP over
> the parent; anywhere else it needs CAP_SETFCAP over the parent now.
> 
> This only affects maps that contain uid 0 of the parent namespace, and
> only when the file was opened by a task with CAP_SETFCAP and is written to
> by one without.  Those writes now fail with -EPERM.
> 
> 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=3




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