qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/3] vpc: support probing of fixed size images


From: Jeff Cody
Subject: Re: [Qemu-devel] [PATCH 0/3] vpc: support probing of fixed size images
Date: Fri, 15 Aug 2014 09:25:14 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

On Fri, Aug 15, 2014 at 07:13:07AM -0600, Eric Blake wrote:
> On 08/15/2014 06:28 AM, Jeff Cody wrote:
> 
> > I worry that will subtly alter current behavior in bad ways.  For
> > instance, take this image chain:
> > 
> >     qemu-img create -f qcow2 foo.img 1G
> >     qemu-img create -f qcow2 -b foo.img bar.img 1G
> > 
> >     qemu-kvm -drive file=bar.img,format=qcow2
> > 
> > 
> > If I understand correctly what you are proposing, that means that
> > qemu-kvm would detect 'foo.img' as raw, while current behavior is to
> > detect it as 'qcow2'.
> > 
> 
> Libvirt ALREADY defaults to detecting foo.img as raw, and refuses to
> grant SELinux permissions for qemu to read bar.img, which causes qemu to
> fail to start due to missing permissions.  All because probing is deemed
> too dangerous (a probe that results in an answer of "raw" is
> trustworthy, a probe that results in any other answer is suspect if the
> file has any remote chance of having once been raw).
> 
> > Although if we do that in conjunction with what Kevin proposed (forbid
> > probing on raw), it would behave 'properly', and bail out before doing
> > something bad.  That could be OK.
> 
> The problem is that you can't forbid probing on raw without forbidding
> probing almost everywhere.  Again, an answer of "raw" is trustworthy, it
> is ALL OTHER answers that are suspect.
> 
> 

I agree that raw is trustworthy (as in, the safest default).  My point
is that I think that silently changing behavior on existing chains
(not everyone uses libvirt and selinux rules) would be bad for
existing users.  I think it best to explicitly warn, and then
deprecate.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]