7:45 a.m.
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?
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.
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. This can result in a very cryptic error message (funny
period (.)):
monitor socket did not show up.: No such file or directory
For instance, base.img is owned by matt (u=rw,go=), a qcow disk qcow.img is linked to
base.img. When a domain using qcow.img is created qcow.img is owned to qemu, but base.img
is not.
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.
I think the suggestion holds even if is only the qemu driver doing the chown.
Best,
matt
11: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 :|
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
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 :|
5294
days inactive
5296
days old
3 comments
2 participants
participants (2)
-
Daniel P. Berrange -
Matthew Farrellee