From: Eric Biggers <ebiggers@kernel.org>
To: Zhan Xusheng <zhanxusheng1024@gmail.com>
Cc: "Theodore Y. Ts'o" <tytso@mit.edu>,
Jaegeuk Kim <jaegeuk@kernel.org>,
linux-fscrypt@vger.kernel.org, linux-kernel@vger.kernel.org,
Zhan Xusheng <zhanxusheng@xiaomi.com>,
stable@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] fscrypt: use the mount idmap for the owner check in fscrypt_ioctl_set_policy()
Date: Sat, 25 Jul 2026 21:34:06 -0700 [thread overview]
Message-ID: <20260726043406.GA1708@sol> (raw)
In-Reply-To: <20260725080004.929328-1-zhanxusheng1024@gmail.com>
[+Cc linux-fsdevel@vger.kernel.org]
On Sat, Jul 25, 2026 at 04:00:04PM +0800, Zhan Xusheng wrote:
> From: Zhan Xusheng <zhanxusheng@xiaomi.com>
>
> fscrypt_ioctl_set_policy() calls inode_owner_or_capable() with
> &nop_mnt_idmap before allowing an encryption policy to be set, instead of
> the idmap of the mount the ioctl was issued on.
>
> fscrypt is used by filesystems that support idmapped mounts (e.g. ext4,
> f2fs), so on such a mount this compares the caller's fsuid against the
> unmapped on-disk owner rather than the mapped owner: the actual owner can
> be wrongly denied with -EACCES and an unrelated caller wrongly allowed.
> Use file_mnt_idmap(filp) instead.
>
> Fixes: 01beba7957a2 ("fs: port inode_owner_or_capable() to mnt_idmap")
> Cc: stable@vger.kernel.org
> Signed-off-by: Zhan Xusheng <zhanxusheng@xiaomi.com>
> ---
> fs/crypto/policy.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/crypto/policy.c b/fs/crypto/policy.c
> index 9915e39362db..c80b24a941ad 100644
> --- a/fs/crypto/policy.c
> +++ b/fs/crypto/policy.c
> @@ -534,7 +534,7 @@ int fscrypt_ioctl_set_policy(struct file *filp, const void __user *arg)
> return -EFAULT;
> policy.version = version;
>
> - if (!inode_owner_or_capable(&nop_mnt_idmap, inode))
> + if (!inode_owner_or_capable(file_mnt_idmap(filp), inode))
> return -EACCES;
>
> ret = mnt_want_write_file(filp);
> --
> 2.43.0
Thanks. I don't think the Fixes commit is quite right: 01beba7957a2
seems to have been a behavior-preserving commit. It even says that it
was "eliminating the possibility of any bugs" :-)
Really it seems a patch to this function was just missing entirely, but
I would probably use 14f3db5542e6 ("ext4: support idmapped mounts").
That's when the other ext4 ioctls got converted to use
file_mnt_user_ns() and the idmap support was enabled on ext4, but this
was missed. (And ext4 was the first fscrypt-capable filesystem to get
idmap support.) As usual, this also needs 'Cc stable'.
I guess I'll plan to take this through the fscrypt tree. I'll update
the tags when committing if there's no other feedback.
- Eric
prev parent reply other threads:[~2026-07-26 4:35 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-25 8:00 [PATCH] fscrypt: use the mount idmap for the owner check in fscrypt_ioctl_set_policy() Zhan Xusheng
2026-07-26 4:34 ` Eric Biggers [this message]
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=20260726043406.GA1708@sol \
--to=ebiggers@kernel.org \
--cc=jaegeuk@kernel.org \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=zhanxusheng1024@gmail.com \
--cc=zhanxusheng@xiaomi.com \
/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.