On 07/09/16 16:06, Austin S. Hemmelgarn wrote: > It hasn't, because there's not any way it can be completely fixed. This > particular case is an excellent example of why it's so hard to fix. To > close this particular hole, BTRFS itself would have to become aware of > whether whoever is running an ioctl is running in a chroot or not, which > is non-trivial to determine to begin with, and even harder when you > factor in the fact that chroot() is a VFS level thing, not a underlying > filesystem thing, while ioctls are much lower level.
Actually, I think the btrfs-receive case might be a little easier to fix and, in my quick reading of the code before doing a test, I thought it even did work this way... I think the fix would be to require that the action of cloning disk blocks required user-mode to provide an FD which has read access to the source blocks. There is little problem with allowing the ioctl to identify the matching subvolume for a UUID but it should require user mode to open the source file for read access using a path before allowing any blocks to be cloned. That way, any VFS-level checks would be done. And, what is more, btrfs-receive could do a file path check to make sure the file being cloned from is within the path that was provided on the command line. -- 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
