[libvirt-users] Stealing ownership: chown user->qemu->root

[Matthew Farrellee]

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