[Libguestfs] virt-sysprep future

[Wanlong Gao]

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
>