Re: [Libguestfs] virt-sysprep future

On Sat, Mar 17, 2012 at 08:16:03PM +0800, Wanlong Gao wrote: > On 03/17/2012 07:49 PM, Richard W.M. Jones wrote: > >> On Sat, Mar 17, 2012 at 06:59:34PM +0800, Wanlong Gao wrote: >>> Does RedHat has a plan to support NBD in RHEL in the future? >> >> Not as far as I know. >> >> guestmount is fast enough for me. With inspection: >> >> $ time sh -c 'guestmount -a /dev/vg_pin/F16x64 -i /tmp/mnt; fusermount -u /tmp/mnt' >> >> real 0m9.999s >> user 0m0.081s >> sys 0m0.377s >> >> Without inspection: >> >> $ time sh -c 'guestmount -a /dev/vg_pin/F16x64 -m /dev/vg_f16x64/lv_root /tmp/mnt; fusermount -u /tmp/mnt' >> >> real 0m6.681s >> user 0m0.074s >> sys 0m0.339s >> >> Currently virt-sysprep runs libguestfs twice (once for inspection, >> once to mount). A virt-sysprep that was rewritten not to be a shell >> script would only run libguestfs once, so there would be ~10 second >> overhead. This overhead is insignificant compared to the downsides of >> using nbd: having to run as root, (in)security, not supporting all >> guests, creating host device nodes, etc. > > [root@Allen ~]# time sh -c 'qemu-nbd -c /dev/nbd0 /dev/sda6; mount /dev/nbd0 ./tmp; umount ./tmp' > > real 0m0.146s > user 0m0.009s > sys 0m0.005s You ought to add kpartx and vgscan in there, for a realistic guest. No, it still won't (quite) be 6-10 seconds. That time is the difference the two methods. The real time for a full virt-sysprep run will be many seconds or minutes. > yes, "having run as root" is one of the shortcomings. > I can't get why nbd causes security problem, do you mean data > corruptions in muti-access? NBD isn't a security issue, but mounting untrusted guest filesystems on your host kernel might be. There's nothing to protect your host (and other guests) from an exploit, and you need to trust that every filesystem driver in your host kernel is hardened against malicious filesystems. When you use the 'mount' command above with the '-t' option, blkid "helpfully" scanned the untrusted disk for a signature and mounted the guest using that filesystem type; it could have been *any* filesystem type, even really obscure and unexpected ones. Filesystems are only the beginning; LVM metadata is another rich source of problems/exploits. The argument against mounting on the host will be even stronger when we add the option of using libvirt with libguestfs. Then you'll be able to hide the untrusted guest in an SVirt [SELinux] container, with cgroups for resource control. > I can't understand the "not supporting all guest", since libguestfs > points to look into the guest disk image, the concept of just read > the disk images' format head is better. Sure, but now try a guest that contains volume groups which conflict with the host. You can (nowadays[1]) mount such VGs using UUIDs, but you have to find the UUIDs first -- complicated -- and you have to trust that the guest's LVM metadata didn't name any of your host PVs, either accidentally or maliciously.

Rich. [1] https://bugzilla.redhat.com/show_bug.cgi?id=207470