6:24 a.m.
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