From: sashiko-bot@kernel.org
Cc: linux-security-module@vger.kernel.org
Subject: Re: [PATCH 3/5] userns: check the writer too before mapping uid 0
Date: Tue, 06 Oct 2026 15:52:55 +0000 [thread overview]
Message-ID: <20261006155256.1FCAB1F0089B@smtp.kernel.org> (raw)
In-Reply-To: <20261006-b4-setfcap-userns-v1-3-f47e7ed66072@toxicpanda.com>
> 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@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
next prev parent reply other threads:[~2026-10-06 15:52 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-06 15:44 [PATCH 0/5] capabilities: close the ways around the CAP_SETFCAP rule for uid 0 Josef Bacik
2026-10-06 15:44 ` [PATCH 1/5] cred: record how far up CAP_SETFCAP reaches Josef Bacik
2026-10-06 15:58 ` sashiko-bot
2026-10-06 15:44 ` [PATCH 2/5] userns: don't let setns() lend the right to map uid 0 Josef Bacik
2026-10-06 15:54 ` sashiko-bot
2026-10-06 15:44 ` [PATCH 3/5] userns: check the writer too before mapping " Josef Bacik
2026-10-06 15:52 ` sashiko-bot [this message]
2026-10-06 15:44 ` [PATCH 4/5] capabilities: limit fscaps to where CAP_SETFCAP reaches Josef Bacik
2026-10-06 15:53 ` sashiko-bot
2026-10-06 15:44 ` [PATCH 5/5] capabilities: don't let ptrace borrow CAP_SETFCAP Josef Bacik
2026-10-06 15:51 ` sashiko-bot
2026-10-08 13:57 ` [PATCH 0/5] capabilities: close the ways around the CAP_SETFCAP rule for uid 0 Serge E. Hallyn
2026-10-08 15:39 ` Josef Bacik
2026-10-08 16:13 ` Serge E. Hallyn
2026-10-09 7:41 ` Christian Brauner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261006155256.1FCAB1F0089B@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.