On Mon, May 8, 2017 at 10:47 PM, Darrick J. Wong
[off-list ref] wrote:

On Mon, May 08, 2017 at 08:47:56PM +0200, Jann Horn wrote:

quoted

On Mon, May 8, 2017 at 8:41 PM, Darrick J. Wong [off-list ref] wrote:

quoted

On Mon, May 08, 2017 at 12:17:53AM +0200, Jann Horn wrote:

quoted

On Sun, May 7, 2017 at 5:58 PM, Darrick J. Wong [off-list ref] wrote:

quoted

Document the new GETFSMAP ioctl that returns the physical layout of a
(disk-based) filesystem.

[...]

quoted

quoted

Also: From a quick glance at the XFS implementation, I don't see any
privilege checks. Am I missing something, or does this API permit an
unprivileged user to determine the number of physical blocks allocated
for any inode, even for inodes the user can't ordinarily see in any
way?

Correct.

What's your reasoning for why this doesn't create any new potential
security issues? For example, as far as I can tell, this would permit

/Any/ ?  That is a huge request to be dropping on me after the vfs patch
gets merged, after a year-long review cycle, etc.

Fair point.

quoted

an unprivileged user to determine with high probability whether a set
of large files with known sizes is stored anywhere in the filesystem, even
across containers or so.

How large?  How high?

Do you have a tool that analyzes a set of st_blocks values and compares
the set to known profiles in order to guess what's on the filesystem?
With what accuracy can it do that, especially without explicit path or
stat data?  The maximum resolution provided by the ioctl is fs block
size, so it's not like you can guess that this 1268432 byte file is
libclangAnalysis.a; all you know is that there are four 310-block files
on this filesystem -- on this system that's the desktop wallpaper, a
file from each of libclang and libgimp, and libc6 from my aarch64 guest.

This would probably become more realistic for larger files, like
conference recordings - with sizes like 200075, 48338, 155870, 134800
blocks -, although admittedly I don't have a specific scenario in mind in
which someone knowing what conference recordings I have on my disk
would be problematic.

You're probably right about this not being a particularly important
concern, and I recognize that if I had wanted a different API, I should
have said so a year ago.