On 09/07/2015 03:08 PM, Chris Webb wrote: > Just one final thought. A second reason we deliberately exclude those > iSCSI devices is that they're actually the drives backing customer VMs, > so any LVM metadata on them should be interpreted by an untrusted guest > kernel and not by the host. Untrusted third parties have complete > control over the contents of the block devices. > > Is LVM well-secured against attacks from block devices containing > malicious LVM metadata? If not, an unexpected change in filtering > behaviour might potentially be a security issue in some environments. > Before, we advised use of the filters to filter out all the LVM layout from guest's disks that is not supposed to be visible on host side that may interfere heavily with the LVM layout on the host then (e.g. same VG/LV names used inside guest as in host). There's a new feature called "systemid" in LVM which got included in lvm2 v2.02.117. This one can be also used to solve this issue (without a need to define filters). Check also https://git.fedorahosted.org/cgit/lvm2.git/tree/man/lvmsystemid.7.in. The trick here is that metadata are marked with an ID of where they were created and you can effectively use this to filter out guest LVs automatically (and vice versa) so these two environments do not interfere with each other... -- Peter _______________________________________________ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
