On Mon, May 8, 2017 at 10:47 PM, Darrick J. Wong <darrick.wong@xxxxxxxxxx> wrote: > On Mon, May 08, 2017 at 08:47:56PM +0200, Jann Horn wrote: >> On Mon, May 8, 2017 at 8:41 PM, Darrick J. Wong <darrick.wong@xxxxxxxxxx> wrote: >> > On Mon, May 08, 2017 at 12:17:53AM +0200, Jann Horn wrote: >> >> On Sun, May 7, 2017 at 5:58 PM, Darrick J. Wong <darrick.wong@xxxxxxxxxx> wrote: >> >> > Document the new GETFSMAP ioctl that returns the physical layout of a >> >> > (disk-based) filesystem. >> [...] >> >> 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. >> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
