* Re: [RFC] fs/ioctl.c: FIBMAP requires CAP_SYS_RAWIO while FIEMAP exposes identical data unprivileged [not found] <_fcorj7Aa0YnzUmrPnqdEbTjLqS6S7t84HKrzsswvKm71LC0uVmTD2cthCwpgeI-296unEpzPZYBNdFFDXjsQvZRtGfTaQlKmcRkiSI4wiQ=@proton.me> @ 2026-05-18 5:08 ` Christoph Hellwig 2026-05-18 16:20 ` Darrick J. Wong 2026-05-19 2:23 ` Theodore Tso 0 siblings, 2 replies; 9+ messages in thread From: Christoph Hellwig @ 2026-05-18 5:08 UTC (permalink / raw) To: Cyber_black Cc: linux-fsdevel@vger.kernel.org, Mark Fasheh, Theodore Ts'o, linux-api On Fri, May 15, 2026 at 05:36:45PM +0000, Cyber_black wrote: > Option B) Add a capability check to ioctl_fiemap() to match FIBMAP. > This restores the intended restriction, at the cost of breaking > unprivileged use of FIEMAP (e.g. filefrag, btrfs tools, e2freefrag). > This option is a larger ABI impact and likely undesirable. > > The preferred fix is Option A, since FIEMAP has been available > unprivileged since 2008 with no reported security issues, and read > access to physical block layout is already implicitly available > through open() permission on the file. No, FIEMAP really should not be available unprivileged. So I think B is the right thing. Can you send a proper patch with a proper signoff? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC] fs/ioctl.c: FIBMAP requires CAP_SYS_RAWIO while FIEMAP exposes identical data unprivileged 2026-05-18 5:08 ` [RFC] fs/ioctl.c: FIBMAP requires CAP_SYS_RAWIO while FIEMAP exposes identical data unprivileged Christoph Hellwig @ 2026-05-18 16:20 ` Darrick J. Wong 2026-05-18 16:22 ` Andy Lutomirski 2026-05-19 2:23 ` Theodore Tso 1 sibling, 1 reply; 9+ messages in thread From: Darrick J. Wong @ 2026-05-18 16:20 UTC (permalink / raw) To: Christoph Hellwig Cc: Cyber_black, linux-fsdevel@vger.kernel.org, Mark Fasheh, Theodore Ts'o, linux-api On Sun, May 17, 2026 at 10:08:13PM -0700, Christoph Hellwig wrote: > On Fri, May 15, 2026 at 05:36:45PM +0000, Cyber_black wrote: > > Option B) Add a capability check to ioctl_fiemap() to match FIBMAP. > > This restores the intended restriction, at the cost of breaking > > unprivileged use of FIEMAP (e.g. filefrag, btrfs tools, e2freefrag). > > This option is a larger ABI impact and likely undesirable. > > > > The preferred fix is Option A, since FIEMAP has been available > > unprivileged since 2008 with no reported security issues, and read > > access to physical block layout is already implicitly available > > through open() permission on the file. > > No, FIEMAP really should not be available unprivileged. So I think B is > the right thing. Can you send a proper patch with a proper signoff? For anyone who might be relying on FIEMAP output to find sparse regions -- don't. FIEMAP is a lowlevel fs debugging interface; it won't tell you about dirty pagecache backed by unwritten disk space. cp was burned by that a decade and a half ago. --D ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC] fs/ioctl.c: FIBMAP requires CAP_SYS_RAWIO while FIEMAP exposes identical data unprivileged 2026-05-18 16:20 ` Darrick J. Wong @ 2026-05-18 16:22 ` Andy Lutomirski 2026-05-19 3:31 ` Darrick J. Wong 0 siblings, 1 reply; 9+ messages in thread From: Andy Lutomirski @ 2026-05-18 16:22 UTC (permalink / raw) To: Darrick J. Wong Cc: Christoph Hellwig, Cyber_black, linux-fsdevel@vger.kernel.org, Mark Fasheh, Theodore Ts'o, linux-api On Mon, May 18, 2026 at 9:21 AM Darrick J. Wong <djwong@kernel.org> wrote: > > On Sun, May 17, 2026 at 10:08:13PM -0700, Christoph Hellwig wrote: > > On Fri, May 15, 2026 at 05:36:45PM +0000, Cyber_black wrote: > > > Option B) Add a capability check to ioctl_fiemap() to match FIBMAP. > > > This restores the intended restriction, at the cost of breaking > > > unprivileged use of FIEMAP (e.g. filefrag, btrfs tools, e2freefrag). > > > This option is a larger ABI impact and likely undesirable. > > > > > > The preferred fix is Option A, since FIEMAP has been available > > > unprivileged since 2008 with no reported security issues, and read > > > access to physical block layout is already implicitly available > > > through open() permission on the file. > > > > No, FIEMAP really should not be available unprivileged. So I think B is > > the right thing. Can you send a proper patch with a proper signoff? > > For anyone who might be relying on FIEMAP output to find sparse regions > -- don't. FIEMAP is a lowlevel fs debugging interface; it won't tell > you about dirty pagecache backed by unwritten disk space. cp was burned > by that a decade and a half ago. > The only way that I'm personally aware of to determine whether ranges in two files are reflinked to each other (and the only efficient way to find identical blocks to, say, archive a large directory without reading all the contents) is FIEMAP. I wrote some code to do this awhile back (not in production use). Yes, I realize that it might have issues with dirty page cache. Is there some other way to do this? Could an API be added that efficiently answers the actual question without revealing information that shouldn't be revealed? --Andy ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC] fs/ioctl.c: FIBMAP requires CAP_SYS_RAWIO while FIEMAP exposes identical data unprivileged 2026-05-18 16:22 ` Andy Lutomirski @ 2026-05-19 3:31 ` Darrick J. Wong 2026-05-19 7:53 ` Andreas Dilger ` (2 more replies) 0 siblings, 3 replies; 9+ messages in thread From: Darrick J. Wong @ 2026-05-19 3:31 UTC (permalink / raw) To: Andy Lutomirski Cc: Christoph Hellwig, Cyber_black, linux-fsdevel@vger.kernel.org, Mark Fasheh, Theodore Ts'o, linux-api On Mon, May 18, 2026 at 09:22:42AM -0700, Andy Lutomirski wrote: > On Mon, May 18, 2026 at 9:21 AM Darrick J. Wong <djwong@kernel.org> wrote: > > > > On Sun, May 17, 2026 at 10:08:13PM -0700, Christoph Hellwig wrote: > > > On Fri, May 15, 2026 at 05:36:45PM +0000, Cyber_black wrote: > > > > Option B) Add a capability check to ioctl_fiemap() to match FIBMAP. > > > > This restores the intended restriction, at the cost of breaking > > > > unprivileged use of FIEMAP (e.g. filefrag, btrfs tools, e2freefrag). > > > > This option is a larger ABI impact and likely undesirable. > > > > > > > > The preferred fix is Option A, since FIEMAP has been available > > > > unprivileged since 2008 with no reported security issues, and read > > > > access to physical block layout is already implicitly available > > > > through open() permission on the file. > > > > > > No, FIEMAP really should not be available unprivileged. So I think B is > > > the right thing. Can you send a proper patch with a proper signoff? > > > > For anyone who might be relying on FIEMAP output to find sparse regions > > -- don't. FIEMAP is a lowlevel fs debugging interface; it won't tell > > you about dirty pagecache backed by unwritten disk space. cp was burned > > by that a decade and a half ago. > > > > The only way that I'm personally aware of to determine whether ranges > in two files are reflinked to each other (and the only efficient way > to find identical blocks to, say, archive a large directory without > reading all the contents) is FIEMAP. I wrote some code to do this > awhile back (not in production use). Yes, I realize that it might > have issues with dirty page cache. > > Is there some other way to do this? Could an API be added that > efficiently answers the actual question without revealing information > that shouldn't be revealed? Well, yes, we *could* make yet another ioctl, but we could also just run fe_physical through a one-way u64 hash function and set FIEMAP_EXTENT_UNKNOWN if (say) you don't have CAP_SYS_RAWIO or something. Then your comparison function might still work... maybe? OTOH nobody really wants Linus roaring at them, so we might all just do absolutely nothing. Also note that FIEMAP still doesn't report devices, so you're still playing with fire on multi-device reflink-aware filesystems like XFS. --D ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC] fs/ioctl.c: FIBMAP requires CAP_SYS_RAWIO while FIEMAP exposes identical data unprivileged 2026-05-19 3:31 ` Darrick J. Wong @ 2026-05-19 7:53 ` Andreas Dilger 2026-05-19 11:45 ` Christoph Hellwig 2026-05-19 20:51 ` Andy Lutomirski 2 siblings, 0 replies; 9+ messages in thread From: Andreas Dilger @ 2026-05-19 7:53 UTC (permalink / raw) To: Darrick J. Wong Cc: Andy Lutomirski, Christoph Hellwig, Cyber_black, linux-fsdevel@vger.kernel.org, Mark Fasheh, Theodore Ts'o, linux-api On May 18, 2026, at 21:31, Darrick J. Wong <djwong@kernel.org> wrote: > > On Mon, May 18, 2026 at 09:22:42AM -0700, Andy Lutomirski wrote: >> On Mon, May 18, 2026 at 9:21 AM Darrick J. Wong <djwong@kernel.org> wrote: >>> >>> On Sun, May 17, 2026 at 10:08:13PM -0700, Christoph Hellwig wrote: >>>> On Fri, May 15, 2026 at 05:36:45PM +0000, Cyber_black wrote: >>>>> Option B) Add a capability check to ioctl_fiemap() to match FIBMAP. >>>>> This restores the intended restriction, at the cost of breaking >>>>> unprivileged use of FIEMAP (e.g. filefrag, btrfs tools, e2freefrag). >>>>> This option is a larger ABI impact and likely undesirable. >>>>> >>>>> The preferred fix is Option A, since FIEMAP has been available >>>>> unprivileged since 2008 with no reported security issues, and read >>>>> access to physical block layout is already implicitly available >>>>> through open() permission on the file. >>>> >>>> No, FIEMAP really should not be available unprivileged. So I think B is >>>> the right thing. Can you send a proper patch with a proper signoff? >>> >>> For anyone who might be relying on FIEMAP output to find sparse regions >>> -- don't. FIEMAP is a lowlevel fs debugging interface; it won't tell >>> you about dirty pagecache backed by unwritten disk space. cp was burned >>> by that a decade and a half ago. >>> >> >> The only way that I'm personally aware of to determine whether ranges >> in two files are reflinked to each other (and the only efficient way >> to find identical blocks to, say, archive a large directory without >> reading all the contents) is FIEMAP. I wrote some code to do this >> awhile back (not in production use). Yes, I realize that it might >> have issues with dirty page cache. >> >> Is there some other way to do this? Could an API be added that >> efficiently answers the actual question without revealing information >> that shouldn't be revealed? > > Well, yes, we *could* make yet another ioctl, but we could also just run > fe_physical through a one-way u64 hash function and set > FIEMAP_EXTENT_UNKNOWN if (say) you don't have CAP_SYS_RAWIO or > something. Then your comparison function might still work... maybe? > > OTOH nobody really wants Linus roaring at them, so we might all just do > absolutely nothing. > > Also note that FIEMAP still doesn't report devices, so you're still > playing with fire on multi-device reflink-aware filesystems like XFS. I've long had a patch to add device printing to FIEMAP/filefrag, but IIRC the last time I tried to submit it upstream it was rejected. Maybe times have changed and there is a chance to get it included. Cheers, Andreas ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC] fs/ioctl.c: FIBMAP requires CAP_SYS_RAWIO while FIEMAP exposes identical data unprivileged 2026-05-19 3:31 ` Darrick J. Wong 2026-05-19 7:53 ` Andreas Dilger @ 2026-05-19 11:45 ` Christoph Hellwig 2026-05-19 20:51 ` Andy Lutomirski 2 siblings, 0 replies; 9+ messages in thread From: Christoph Hellwig @ 2026-05-19 11:45 UTC (permalink / raw) To: Darrick J. Wong Cc: Andy Lutomirski, Christoph Hellwig, Cyber_black, linux-fsdevel@vger.kernel.org, Mark Fasheh, Theodore Ts'o, linux-api On Mon, May 18, 2026 at 08:31:26PM -0700, Darrick J. Wong wrote: > > The only way that I'm personally aware of to determine whether ranges > > in two files are reflinked to each other (and the only efficient way > > to find identical blocks to, say, archive a large directory without > > reading all the contents) is FIEMAP. I wrote some code to do this > > awhile back (not in production use). Yes, I realize that it might > > have issues with dirty page cache. > > > > Is there some other way to do this? Could an API be added that > > efficiently answers the actual question without revealing information > > that shouldn't be revealed? > > Well, yes, we *could* make yet another ioctl, but we could also just run > fe_physical through a one-way u64 hash function and set > FIEMAP_EXTENT_UNKNOWN if (say) you don't have CAP_SYS_RAWIO or > something. Then your comparison function might still work... maybe? What is the actual use case for that dedup detection? I.e. what is considered duplicate? Does the application already have candidate ranges or does it scan the output for all fіles? For xfs the rmap can directly tell you what is shared, but I can't think of a good way to expose that, but part of that might be that I don't understand what question is asked and why. Note the FIEMAP output can give you the wrong answer, e.g. with XFS and multiple devices, or for file systems that can do tail packing and have small amounts of data for multiple files in the same block. > Also note that FIEMAP still doesn't report devices, so you're still > playing with fire on multi-device reflink-aware filesystems like XFS. or even on f2fs despite the lack of reflink support if the caller is dumb enough. All that of course depends on what the caller is doing based on the FIEMAP output. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC] fs/ioctl.c: FIBMAP requires CAP_SYS_RAWIO while FIEMAP exposes identical data unprivileged 2026-05-19 3:31 ` Darrick J. Wong 2026-05-19 7:53 ` Andreas Dilger 2026-05-19 11:45 ` Christoph Hellwig @ 2026-05-19 20:51 ` Andy Lutomirski 2 siblings, 0 replies; 9+ messages in thread From: Andy Lutomirski @ 2026-05-19 20:51 UTC (permalink / raw) To: Darrick J. Wong Cc: Christoph Hellwig, Cyber_black, linux-fsdevel@vger.kernel.org, Mark Fasheh, Theodore Ts'o, linux-api On Mon, May 18, 2026 at 8:31 PM Darrick J. Wong <djwong@kernel.org> wrote: > > On Mon, May 18, 2026 at 09:22:42AM -0700, Andy Lutomirski wrote: > > On Mon, May 18, 2026 at 9:21 AM Darrick J. Wong <djwong@kernel.org> wrote: > > > > > > On Sun, May 17, 2026 at 10:08:13PM -0700, Christoph Hellwig wrote: > > > > On Fri, May 15, 2026 at 05:36:45PM +0000, Cyber_black wrote: > > > > > Option B) Add a capability check to ioctl_fiemap() to match FIBMAP. > > > > > This restores the intended restriction, at the cost of breaking > > > > > unprivileged use of FIEMAP (e.g. filefrag, btrfs tools, e2freefrag). > > > > > This option is a larger ABI impact and likely undesirable. > > > > > > > > > > The preferred fix is Option A, since FIEMAP has been available > > > > > unprivileged since 2008 with no reported security issues, and read > > > > > access to physical block layout is already implicitly available > > > > > through open() permission on the file. > > > > > > > > No, FIEMAP really should not be available unprivileged. So I think B is > > > > the right thing. Can you send a proper patch with a proper signoff? > > > > > > For anyone who might be relying on FIEMAP output to find sparse regions > > > -- don't. FIEMAP is a lowlevel fs debugging interface; it won't tell > > > you about dirty pagecache backed by unwritten disk space. cp was burned > > > by that a decade and a half ago. > > > > > > > The only way that I'm personally aware of to determine whether ranges > > in two files are reflinked to each other (and the only efficient way > > to find identical blocks to, say, archive a large directory without > > reading all the contents) is FIEMAP. I wrote some code to do this > > awhile back (not in production use). Yes, I realize that it might > > have issues with dirty page cache. > > > > Is there some other way to do this? Could an API be added that > > efficiently answers the actual question without revealing information > > that shouldn't be revealed? > > Well, yes, we *could* make yet another ioctl, but we could also just run > fe_physical through a one-way u64 hash function and set > FIEMAP_EXTENT_UNKNOWN if (say) you don't have CAP_SYS_RAWIO or > something. Then your comparison function might still work... maybe? > > OTOH nobody really wants Linus roaring at them, so we might all just do > absolutely nothing. > > Also note that FIEMAP still doesn't report devices, so you're still > playing with fire on multi-device reflink-aware filesystems like XFS. > A hash would be fine for me. But really a nicer interface would translate logical ranges in a file to some range identifier, where: - It would be consistent with page cache. So holes are only reported if the current logical contents is a hole. - It would return reliably different identifiers for ranges that do not have identical contents. - It would usually return the same identifier for ranges that are known to the FS to have identical contents. - It would not return the same identifier for files on different backing devices that just happen to be backed by the same offset within their respective backing devices. - It would not necessarily return values that are consistent across a remount. But maybe some kind of mount id would be around to at least detect this happening. Fun bonus points: if the range is dirty in page cache, tell me, and if it's not dirty, then, on supporting filesystems, return a value that will *change* if someone writes to the file and it get undirtied again. IOW it would be nice to be able to use this to efficiently scan through a file and see what extents may have been modified since the last scan. But this would be complex. I couldn't care less about the actual location of a file. Anyway, this is a bit of a pie-in-the-sky thought. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC] fs/ioctl.c: FIBMAP requires CAP_SYS_RAWIO while FIEMAP exposes identical data unprivileged 2026-05-18 5:08 ` [RFC] fs/ioctl.c: FIBMAP requires CAP_SYS_RAWIO while FIEMAP exposes identical data unprivileged Christoph Hellwig 2026-05-18 16:20 ` Darrick J. Wong @ 2026-05-19 2:23 ` Theodore Tso 2026-05-19 11:42 ` Christoph Hellwig 1 sibling, 1 reply; 9+ messages in thread From: Theodore Tso @ 2026-05-19 2:23 UTC (permalink / raw) To: Christoph Hellwig Cc: Cyber_black, linux-fsdevel@vger.kernel.org, Mark Fasheh, linux-api On Sun, May 17, 2026 at 10:08:13PM -0700, Christoph Hellwig wrote: > On Fri, May 15, 2026 at 05:36:45PM +0000, Cyber_black wrote: > > Option B) Add a capability check to ioctl_fiemap() to match FIBMAP. > > This restores the intended restriction, at the cost of breaking > > unprivileged use of FIEMAP (e.g. filefrag, btrfs tools, e2freefrag). > > This option is a larger ABI impact and likely undesirable. > > > > The preferred fix is Option A, since FIEMAP has been available > > unprivileged since 2008 with no reported security issues, and read > > access to physical block layout is already implicitly available > > through open() permission on the file. > > No, FIEMAP really should not be available unprivileged. So I think B is > the right thing. Can you send a proper patch with a proper signoff? > I disagree. As I recall, we discussed whether or not FIEMAP needed to be unprivileged many years ago, and it was a conscious choice not to require root privs. I don't believe it is a security issue to allow users to see the logical -> physical block mappings for inodes. Users might misuse it, and we did have that issue many years ago when cp attempted to use FIEMAP in a way way that it wasn't intended to be used[1]. However, that was over 15 years ago. [1] https://lwn.net/Articles/429345/ But just because an interface could be misued doesn't mean that we should restrict it, IMHO. - Ted ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [RFC] fs/ioctl.c: FIBMAP requires CAP_SYS_RAWIO while FIEMAP exposes identical data unprivileged 2026-05-19 2:23 ` Theodore Tso @ 2026-05-19 11:42 ` Christoph Hellwig 0 siblings, 0 replies; 9+ messages in thread From: Christoph Hellwig @ 2026-05-19 11:42 UTC (permalink / raw) To: Theodore Tso Cc: Christoph Hellwig, Cyber_black, linux-fsdevel@vger.kernel.org, Mark Fasheh, linux-api On Mon, May 18, 2026 at 10:23:27PM -0400, Theodore Tso wrote: > I disagree. As I recall, we discussed whether or not FIEMAP needed to > be unprivileged many years ago, and it was a conscious choice not to > require root privs. I don't believe it is a security issue to allow > users to see the logical -> physical block mappings for inodes. Users have no business even known it. It is a side channel that can easily leak information for attackers that know allocation policies. And as the reported state it also is inconsistent with how FIBMAP has behaved since the damn of time. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2026-05-19 20:52 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <_fcorj7Aa0YnzUmrPnqdEbTjLqS6S7t84HKrzsswvKm71LC0uVmTD2cthCwpgeI-296unEpzPZYBNdFFDXjsQvZRtGfTaQlKmcRkiSI4wiQ=@proton.me>
2026-05-18 5:08 ` [RFC] fs/ioctl.c: FIBMAP requires CAP_SYS_RAWIO while FIEMAP exposes identical data unprivileged Christoph Hellwig
2026-05-18 16:20 ` Darrick J. Wong
2026-05-18 16:22 ` Andy Lutomirski
2026-05-19 3:31 ` Darrick J. Wong
2026-05-19 7:53 ` Andreas Dilger
2026-05-19 11:45 ` Christoph Hellwig
2026-05-19 20:51 ` Andy Lutomirski
2026-05-19 2:23 ` Theodore Tso
2026-05-19 11:42 ` Christoph Hellwig
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox