[Libguestfs] virt-sysprep future
Wanlong Gao
gaowanlong at cn.fujitsu.com
Sat Mar 17 14:24:55 UTC 2012
On 03/17/2012 09:57 PM, Richard W.M. Jones wrote:
> 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 at 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.
Thank you very much for explain so clearly Rich.
I have got so much information from you about this.
Now, I'm waiting for your new virt-sysprep. :-D
Regards,
Wanlong Gao
>
> Rich.
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=207470
>
More information about the Libguestfs
mailing list