1:33 a.m.
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 :|