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. -- 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
