Re: [PATCH] btrfs: use mount idmap for defrag permission check

Qu Wenruo <[email protected]>
Newsgroups gmane.linux.kernel,gmane.comp.file-systems.btrfs,gmane.linux.file-systems
Message-ID <[email protected]>

在 2026/8/14 02:41, Seth Forshee 写道:
> On Thu, Aug 13, 2026 at 04:04:05PM +0930, Qu Wenruo wrote:
>>
>>
>> 在 2026/8/13 13:11, Tao Cui 写道:
>>> From: Tao Cui <[email protected]>
>>>
>>> btrfs_ioctl_defrag() checks MAY_WRITE with nop_mnt_idmap, which skips
>>> the mount idmap.  On an idmapped mount the owner comparison then uses
>>> the caller's fsuid against the raw on-disk uid, dropping the mapping.
>>> Every other permission/owner check in btrfs ioctl uses
>>> file_mnt_idmap(file) (e.g. :1152, :1310, :1946); this one missed it.
>>>
>>> Switch to file_mnt_idmap(file).  It equals nop_mnt_idmap on a normal
>>> mount, and the check stays behind !capable(CAP_SYS_ADMIN), so only
>>> unprivileged callers on idmapped btrfs change.  The RO-fd note in the
>>> comment above is about the file descriptor, not this inode check, and
>>> is unaffected.
>>>
>>> Signed-off-by: Tao Cui <[email protected]>
>>
>> Fixes: 4609e1f18e19 ("fs: port ->permission() to pass mnt_idmap")
> 
> This is a misattribution. Using nop_mnt_idmap there keeps the behavior
> the same as it was before the commit. Switching to the mount idmap opens
> up BTRFS_IOC_DEFRAG* to idmapped users when they weren't before, which
> is a separate policy decision that didn't belong in that change.

OK, removed from for-next, and will not add the fixes tag.
> 
> Saying that these ioctls should be allowed for idmapped users just
> because others are isn't a good justification. Why are these ioctls safe
> for idmapped users?  Do they actually require this capability?

I'll let the author to do the explanation.

Thanks,
Qu

> 
> Thanks,
> Seth
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.