[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