On 2016-09-09 12:18, David Sterba wrote:
On Wed, Sep 07, 2016 at 07:58:30AM -0400, Austin S. Hemmelgarn wrote:
On 2016-09-06 13:20, Graham Cobb wrote:
Thanks to Austin and Duncan for their replies.
On 06/09/16 13:15, Austin S. Hemmelgarn wrote:
On 2016-09-05 05:59, Graham Cobb wrote:
Does the "path" argument of btrfs-receive mean that *all* operations are
confined to that path? For example, if a UUID or transid is sent which
refers to an entity outside the path will that other entity be affected
or used?
As far as I know, no, it won't be affected.
Is it possible for a file to be created containing shared
extents from outside the path?
As far as I know, the only way for this to happen is if you're
referencing a parent subvolume for a relative send that is itself
sharing extents outside of the path. From a practical perspective,
unless you're doing deduplication on the receiving end, the this
shouldn't be possible.
Unfortunately that is not the case. I decided to do some tests to see
what happens. It is possible for a receive into one path to reference
and access a subvolume from a different path on the same btrfs disk. I
have created a bash script to demonstrate this at:
https://gist.github.com/GrahamCobb/c7964138057e4e092a75319c9fb240a3
This does require the attacker to know the (source) subvolume UUID they
want to copy. I am not sure how hard UUIDs are to guess.
Oh, I forgot about the fact that it checks the whole filesystem for
referenced source subvolumes.
What if the stream is verified first? Ie. look if there are the
operations using subolumes not owned by the user.
I think that extending the ioctl to require proof of access to the
source being cloned from would be a better approach to this, as this is
an issue with the ioctl in general, it's just discussion of send/receive
that brought this up. I'm actually kind of surprised that this didn't
get noticed before, seeing as it's a pretty significant and not all that
difficult to use information leak. Ideally, this needs to be decided
before the VFS layer clone ioctl gets finalized.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
