Matthew Farrellee
2010-Jan-25 13:45 UTC
[libvirt-users] 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
Daniel P. Berrange
2010-Jan-25 17:33 UTC
[libvirt-users] Stealing ownership: chown user->qemu->root
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 :|