On Thu, Apr 21, 2016 at 08:35:43 +0200, Martin Kletzander wrote: > On Wed, Apr 20, 2016 at 01:33:15PM -0400, Cole Robinson wrote: > >virsh doesn't reject or absolutify a passed relative path, which > >can give unexpected results. Convert a relative path to an absolute > >one before calling the API > > > >https://bugzilla.redhat.com/show_bug.cgi?id=1300177 > >--- > > tools/virsh-domain.c | 11 +++++++++-- > > 1 file changed, 9 insertions(+), 2 deletions(-) > > > > This is a nasty bug, that's for sure. However, shouldn't our API be > fixed rather than just virsh? There's still a bug there. > > Moreover, IIUC the path you give it should be relative to the volume (or > something specific) and not the path you're calling it with. Well, it > could make sense to make it relative to CWD, but what if it's called > from a remote client? That path might not exist at all. I think it > should be relative to something else and the volume seems the most > sensible (after thinking about it for roughly 14 seconds). Yes this is entirely true. We also forbid relative paths for the top level disks and since the target of block copy can eventually become a top level disks the approach chosen by the patch is wrong. NACK
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list