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. By the way, this is exactly the same whether or not the --chroot option is specified on the "btrfs receive" command. The next question this raises for me is whether this means that processes in a chroot or in a container (or in a mandatory access controls environment) can access files outside the chroot/container if they know the UUID of the subvolume? After all, btrfs-receive uses IOCTLs that any program running as root can use. Graham -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
