Thanks for the quick reply. On 01/25/2010 12:33 PM, Daniel P. Berrange wrote: > 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.
I'm guessing I could also change this to a user other than qemu or root. Is this something I can change on a per guest basis? > 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. This is good to hear. When will the feature show up? I assume such a feature will mean files don't end up owned at root after the domain is destroyed. >> 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. You already lock down /var/lib/libvirt/images, but if someone could guess a VM's disk image I can see the problem. >> 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. Great. >> 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. Good point about remote, which isn't a common use case for me at all. BTW, I noticed on EL5 that I got AVCs when trying to install a VM from an ISO in my home directory. I'm guessing in the future virt-manager will manipulate the ISO with these APIs and not have such a problem? > 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. Cool. When is this happening? Hopefully for EL6. Best, matt _______________________________________________ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
