On Tue, 2015-12-15 at 14:42 +0000, Hugo Mills wrote: > I would suggest trying to migrate to a state where detecting more > than one device with the same UUID and devid is cause to prevent the > FS from mounting, unless there's also a "mount_duplicates_yes_i_ > know_this_is_dangerous_and_i_know_what_im_doing" mount flag present, > for the multipathing people. That will break existing userspace > behaviour for the multipathing case, but the migration can probably > be > managed. (e.g. NFS has successfully changed default behaviour for one > of its mount options in the last few(?) years).
I don't think that a single mountpoint a la "force-and-do-it" is a proper solution here. It would still open surface for attacks and also for accidents. In the case mutli-pathing is used, the only realistic way seems to be manually specifying the devices a la device=/dev/sda,/dev/sdb. Of course btrfs would stil use the UUIDs/deviceIDs of these, but *only* of those devices that have been whitelisted with the device=option. In the case of a general "mount_duplicates_yes_iknow_th..." option you could end up with having e.g. three duplicates, two being actually mutli-paths, and the third one being a losetup or USB clone of the image,... again allowing for the aforementioned attacks to happen, and again allowing for severe corruption to occur.
smime.p7s
Description: S/MIME cryptographic signature
