From: "Darrick J. Wong" <darrick.wong@oracle.com> To: Jann Horn <jannh@google.com> Cc: Michael Kerrisk-manpages <mtk.manpages@gmail.com>, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, Linux API <linux-api@vger.kernel.org>, linux-man@vger.kernel.org Subject: Re: [PATCH] ioctl_getfsmap.2: document the GETFSMAP ioctl Date: Mon, 8 May 2017 18:53:24 -0700 [thread overview] Message-ID: <20170509015324.GM5973@birch.djwong.org> (raw) In-Reply-To: <CAG48ez0iLRazKvXty9CG8ENXvkG6b1xjO0Q75p+16HKNptFnow@mail.gmail.com> On Tue, May 09, 2017 at 12:54:57AM +0200, Jann Horn wrote: > On Mon, May 8, 2017 at 10:47 PM, Darrick J. Wong > <darrick.wong@oracle.com> 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@oracle.com> 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@oracle.com> 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. TBH, I /did/ build a (crappy) tool that tries to construct fingerprints based on the fsmaps it finds for each inode number. It works reasonably well for identifying the existence (and number) of reflink clones of any part of the file tree that you can stat and FIEMAP. It also works (sort of) if you have multiple separate filesystems with roughly the same fs trees in them. Mixing things into one big file produces a lot of noise, and data files are harder to pick out unless they're deduped. > 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. I don't mind people bringing up specific concerns and making specific requests for the rest of the 4.12 cycle since it's relatively easy to make small changes to the interface (e.g. adding a capability check). --D > -- > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: "Darrick J. Wong" <darrick.wong-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> To: Jann Horn <jannh-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> Cc: Michael Kerrisk-manpages <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, linux-xfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux API <linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Subject: Re: [PATCH] ioctl_getfsmap.2: document the GETFSMAP ioctl Date: Mon, 8 May 2017 18:53:24 -0700 [thread overview] Message-ID: <20170509015324.GM5973@birch.djwong.org> (raw) In-Reply-To: <CAG48ez0iLRazKvXty9CG8ENXvkG6b1xjO0Q75p+16HKNptFnow-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> On Tue, May 09, 2017 at 12:54:57AM +0200, Jann Horn wrote: > On Mon, May 8, 2017 at 10:47 PM, Darrick J. Wong > <darrick.wong-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> 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-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> 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-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> 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. TBH, I /did/ build a (crappy) tool that tries to construct fingerprints based on the fsmaps it finds for each inode number. It works reasonably well for identifying the existence (and number) of reflink clones of any part of the file tree that you can stat and FIEMAP. It also works (sort of) if you have multiple separate filesystems with roughly the same fs trees in them. Mixing things into one big file produces a lot of noise, and data files are harder to pick out unless they're deduped. > 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. I don't mind people bringing up specific concerns and making specific requests for the rest of the 4.12 cycle since it's relatively easy to make small changes to the interface (e.g. adding a capability check). --D > -- > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-05-09 1:53 UTC|newest] Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-05-07 15:58 [PATCH] ioctl_getfsmap.2: document the GETFSMAP ioctl Darrick J. Wong 2017-05-07 22:17 ` Jann Horn 2017-05-08 18:41 ` Darrick J. Wong 2017-05-08 18:41 ` Darrick J. Wong 2017-05-08 18:47 ` Jann Horn 2017-05-08 20:47 ` Darrick J. Wong 2017-05-08 20:47 ` Darrick J. Wong 2017-05-08 22:54 ` Jann Horn 2017-05-09 1:53 ` Darrick J. Wong [this message] 2017-05-09 1:53 ` Darrick J. Wong 2017-05-09 21:17 ` Eric Biggers 2017-05-09 21:17 ` Eric Biggers 2017-05-10 16:38 ` Theodore Ts'o 2017-05-10 19:27 ` Eric W. Biederman 2017-05-10 20:14 ` Darrick J. Wong 2017-05-10 20:14 ` Darrick J. Wong 2017-05-11 5:10 ` Eric Biggers 2017-05-11 5:10 ` Eric Biggers 2017-05-14 1:41 ` Andreas Dilger 2017-05-14 4:25 ` Darrick J. Wong 2017-05-14 4:25 ` Darrick J. Wong 2017-05-14 13:56 ` Andy Lutomirski 2017-05-14 13:56 ` Andy Lutomirski 2017-05-18 2:04 ` Darrick J. Wong 2017-05-18 2:04 ` Darrick J. Wong -- strict thread matches above, loose matches on Subject: below -- 2017-02-18 1:17 [RFC PATCH v6 0/8] vfs/xfs/ext4: GETFSMAP support Darrick J. Wong 2017-02-21 22:14 ` [PATCH] ioctl_getfsmap.2: document the GETFSMAP ioctl Darrick J. Wong
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=20170509015324.GM5973@birch.djwong.org \ --to=darrick.wong@oracle.com \ --cc=jannh@google.com \ --cc=linux-api@vger.kernel.org \ --cc=linux-ext4@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-man@vger.kernel.org \ --cc=linux-xfs@vger.kernel.org \ --cc=mtk.manpages@gmail.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: linkBe 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.