7:23 a.m.
On Wed, Jan 27, 2010 at 07:24:41AM -0500, Matthew Farrellee wrote:
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?
It is changable on a per-host basis only. While you could change it to
anything, our recommendation is to stick with just qemu or root as
needed. It is primarily for the distro to determine the default unprivileged
user account.
> 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?
In the next releae...
I assume such a feature will mean files don't end up owned at
root
after the domain is destroyed.
Yes, that's correct - it stops all ownership changes.
>> 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?
RHEL5 does not have the sVirt support, so its the users responsibility to
ensure correct SELinux labelling if storing images in unusual locations.
RHEL6 / Fedora >= 11 has sVirt which takes care of setting all labelling
so it should not be a problem, except in arena of NFS or other really
rubbish filesystems like FAT.
> 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.
Not likely for RHEL-6.0, but in perhaps a later update. It is dependant
on us sorting out the final issue of setting up networking as an unprivilegd
user
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 :|