libvirt users - Jan 2010 - Stealing ownership: chown user->qemu->root

F12, libvirt 0.7.1-15, qemu 0.11.0-12, 32 bit

I recently discovered that libvirt is stealing ownership of my disk images. How
can I make it stop?

I have a disk image in my home directory, owned by matt. When I create a domain
that uses the disk it gets chowned to qemu.qemu. When the domain terminates it
is owned by root.root. I've lost access to the file.

It has been suggested that the user->qemu happens to make sure that the qemu
account can read/write the file. chmod'ing would be far better and avoid
this problem. It appears that libvirt just assumes the disk image was owned by
root before being chown'd to qemu.

Another problem with this is qcow disks. If chown'ing to qemu is to ensure
that qemu has access to all the disks needed for the domain, it fails for qcow,
because the base disk is not chown'd as well. This can result in a very
cryptic error message (funny period (.)):

  monitor socket did not show up.: No such file or directory

For instance, base.img is owned by matt (u=rw,go=), a qcow disk qcow.img is
linked to base.img. When a domain using qcow.img is created qcow.img is owned to
qemu, but base.img is not.

Instead of chown'ing, will libvirt provide an error that could cover both
these situations? The virt-manager GUI (or virsh TUI) could interpret that error
and chmod the proper files transparently, or preemptively chmod the required
files. Users of the libvirt API would have to make sure things are setup
properly at first and would not have to worry about side-effect changes made by
libvirtd.

I think the suggestion holds even if is only the qemu driver doing the chown.

Best,


matt

On Mon, Jan 25, 2010 at 08:45:01AM -0500, Matthew Farrellee
wrote:
> F12, libvirt 0.7.1-15, qemu 0.11.0-12, 32 bit
> 
> I recently discovered that libvirt is stealing ownership of my disk
> images. How can I make it stop?
Edit /etc/libvirt/qemu.conf and set the 'user' and 'group'
config options
back to 'root'.  NB all your guests will now run as root again, instead
of as 'qemu', and you'll need to make sure your disk images are
owned by
root too since QEMU lacks CAP_DAC_OVERRIDE which is what 'root' normally
uses to access other users' files.

NB, current libvirt git has an explicit option to turn off file ownership
management, meaning it is upto end user to ensure it is writable by
the QEMU user when required.
> I have a disk image in my home directory, owned by matt. When I create
> a domain that uses the disk it gets chowned to qemu.qemu. When the domain
> terminates it is owned by root.root. I've lost access to the file.
> 
> It has been suggested that the user->qemu happens to make sure that the
> qemu account can read/write the file. chmod'ing would be far better and
> avoid this problem. It appears that libvirt just assumes the disk image
> was owned by root before being chown'd to qemu.
The only option with chmod'ing would be to give it world read/write
access, which is less desirable because it means other daemons on the
system could access it which is a security hole. We went for chmod
because it lets us ensure only QEMU can access it.

One other option we can investigate though is to use  setfacl() to add
an ACL for the 'qemu' user. This might have interoperability problems,
but it would at least avoid the problem of ownership restoration.
> Another problem with this is qcow disks. If chown'ing to qemu is to
> ensure that qemu has access to all the disks needed for the domain, 
> it fails for qcow, because the base disk is not chown'd as well. 
That's a bug in the F12 code, which we've addressed in GIT - it should
have been processing backing files too.
> Instead of chown'ing, will libvirt provide an error that could cover 
> both these situations? The virt-manager GUI (or virsh TUI) could 
> interpret that error and chmod the proper files transparently, or 
> preemptively chmod the required files. Users of the libvirt API would
> have to make sure things are setup properly at first and would not 
> have to worry about side-effect changes made by libvirtd.
The idea for the future is that apps use the storage APIs to create disk
files, which lets them directly request the correct ownership. You can't
delegate the chmod() itself to virt-manager because that app will either
not be running on the same machine as the VM, or possibly not have sufficient
privileges to change the access to allow QEMU.

The second issue, is that this is all wrt the libvirt system daemon instance.
This is intended for server virt. Your use case is really desktop virt and
for that we are getting ready to switch to the libvirt session daemon 
instance where absolutely everything runs as your own user ID, so there'd
be no switching of UIDs at all.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|