[libvirt] [PATCHv2 4/5] storage: don't follow backing chain symlinks too eagerly

Eric Blake eblake at redhat.com
Fri Feb 15 22:42:35 UTC 2013


On 02/15/2013 03:08 PM, Peter Krempa wrote:
> On 02/15/13 21:38, Eric Blake wrote:
>> If you have a qcow2 file /path1/to/file pointed to by symlink
>> /path2/symlink, and pass qemu /path2/symlink, then qemu treats
>> a relative backing file in the qcow2 metadata as being relative
>> to /path2, not /path1/to.  Yes, this means that it is possible
>> to create a qcow2 file where the choice of WHICH directory and
>> symlink you access its contents from will then determine WHICH
>> backing file (if any) you actually find; the results can be
>> rather screwy, but we have to match what qemu does.
>>
>> Libvirt and qemu default to creating absolute backing file
>> names, so most users don't hit this.  But at least VDSM uses
>> symlinks and relative backing names alongside the
>> --reuse-external flags to libvirt snapshot operations, with the
>> result that libvirt was failing to follow the intended chain of
>> backing files, and then backing files were not granted the
>> necessary sVirt permissions to be opened by qemu.
>>
>> See https://bugzilla.redhat.com/show_bug.cgi?id=903248 for
>> more gory details.  This fixes a regression introduced in
>> commit 8250783.
>>
>> I tested this patch by creating the following chain:

and that chain is more-or-less in patch 5/5.

>> +        } else if (!d_len) {
> 
> I'd go for (d_len == 0) here so that it will not be confused with pointers.

Done.

> 
>> +            start = ".";
>> +            d_len = 1;
>> +        }
>> +        if (virAsprintf(&combined, "%.*s/%s", (int)d_len, start,
>> path) < 0) {
>> +            virReportOOMError();
>> +            goto cleanup;
>> +        }
>>       }
> 
> Otherwise looks reasonable.
> 
> ACK.

Will push shortly.  Thanks for the review.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 621 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20130215/959ba4e5/attachment-0001.sig>


More information about the libvir-list mailing list