Libguestfs - Mar 2017 - Re: [PATCH 2/4] v2v: chmod original OVA file if running as root (RHBZ#1430680).

On Mon, 13 Mar 2017 14:47:43 +0000
"Richard W.M. Jones" <rjones@redhat.com> wrote:
> In the case where we are going to read the disk directly from the OVA
> file (partial = true), we will create a qcow2 image backed by the OVA.
> If running as root, libvirt will run qemu as a non-root user (because
> of no qemu:///session support for root, which is a libvirt bug).  qemu
> will not be able to read the backing file and thus will fail.
I was under the impression that libvirt chmods/chowns all disks so they
are accessible by QEMU. Is this a bug in libvirt because the owner is
only changed for the overlay but not for all the backing files?

Or is libvirt just being sloppy in the job and it only changes the owner
of the file but does not check the path if there is any permission
problem along the way on some directory? (Although I'm not sure what
would be a proper response from libvirt in this case.)


    Tomas

-- 
Tomáš Golembiovský <tgolembi@redhat.com>

On Tue, Mar 14, 2017 at 12:48:20PM +0100, Tomáš Golembiovský
wrote:
> On Mon, 13 Mar 2017 14:47:43 +0000
> "Richard W.M. Jones" <rjones@redhat.com> wrote:
> 
> > In the case where we are going to read the disk directly from the OVA
> > file (partial = true), we will create a qcow2 image backed by the OVA.
> > If running as root, libvirt will run qemu as a non-root user (because
> > of no qemu:///session support for root, which is a libvirt bug).  qemu
> > will not be able to read the backing file and thus will fail.
> 
> I was under the impression that libvirt chmods/chowns all disks so they
> are accessible by QEMU. Is this a bug in libvirt because the owner is
> only changed for the overlay but not for all the backing files?
> 
> Or is libvirt just being sloppy in the job and it only changes the owner
> of the file but does not check the path if there is any permission
> problem along the way on some directory? (Although I'm not sure what
> would be a proper response from libvirt in this case.)
Libvirt won't recursively change directory permissions - only the leaf
node file permissions. So you need to make sure the parent directories
are not overly restrictive in permissions. We do this because we don't
want to open up security holes that allow unwanted access to other
files in the directories.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|

On Tue, Mar 14, 2017 at 11:50:37AM +0000, Daniel P. Berrange
wrote:
> On Tue, Mar 14, 2017 at 12:48:20PM +0100, Tomáš Golembiovský wrote:
> > On Mon, 13 Mar 2017 14:47:43 +0000
> > "Richard W.M. Jones" <rjones@redhat.com> wrote:
> > 
> > > In the case where we are going to read the disk directly from the
OVA
> > > file (partial = true), we will create a qcow2 image backed by the
OVA.
> > > If running as root, libvirt will run qemu as a non-root user
(because
> > > of no qemu:///session support for root, which is a libvirt bug). 
qemu
> > > will not be able to read the backing file and thus will fail.
> > 
> > I was under the impression that libvirt chmods/chowns all disks so
they
> > are accessible by QEMU. Is this a bug in libvirt because the owner is
> > only changed for the overlay but not for all the backing files?
> > 
> > Or is libvirt just being sloppy in the job and it only changes the
owner
> > of the file but does not check the path if there is any permission
> > problem along the way on some directory? (Although I'm not sure
what
> > would be a proper response from libvirt in this case.)
> 
> Libvirt won't recursively change directory permissions - only the leaf
> node file permissions. So you need to make sure the parent directories
> are not overly restrictive in permissions. We do this because we don't
> want to open up security holes that allow unwanted access to other
> files in the directories.
The problem is not any of the above.  The disks and their parent
directories are already readable by the UID running virt-v2v (root).

The problem is that libvirt does not have a concept of qemu:///session
for root.  Thus when you run virt-v2v as root, it uses qemu:///system,
and that runs qemu as a non-root user (qemu.qemu or similar).  That
process cannot see the disks.  If we ran qemu as root, everything
would work fine and no workarounds would be needed.

This bug has been open against libvirt for 4+ years:

  https://bugzilla.redhat.com/show_bug.cgi?id=890291

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/