Re: latest F19 policy update killed qemu ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 12/17/2013 07:59 AM, Daniel J Walsh wrote:
after some tinkering I've applied svirt_image_t to /var/lib/libvirt/images
and everything is functioning, however "restorecon -RF
/var/lib/libvirt/images" brings everything back to virt_image_t , hmm?

libvirt is supposed to change the label of a virt_image_t to
svirt_image_t:MCSLABEL  when the virtual machine is running, and then change
it back to virt_image_t when the VM is finished.  Running VMs can only
read/write svirt_image_t.  The problem is you should not be running restorecon
on this directory.

svirt_image_t is supposed to be in a type that restorecon will not change.

If you stop and restart the VM everything should be labeled correctly.

Thanks for the explanation Daniel, now it makes sence why it's refusing to startup those vm's - I'm using qcow2 external snapshots :

$ qemu-img create -f qcow2 -b foo.qcow2 foo-snap.qcow2

and apparently that is causing issues as either libvirt is not relabeling things properly or something else is wrong but at the start time VM has no access to base image[s] (sometimes I daisy-chain snapshots up to 3 levels). However the fact is - it stopped working yesterday, and this box was always in enforcing mode and functioning properly. I did not notice any updates to virtualization layer, however there was selinux-policy* version bump, thus I'm here.

At the moment I had to switch to the Permissive since only with "wrong" labels I can start VMs.

I will change labels back to virt_image_t in the meantime...

Should I be filing a bug or is there something else that could be done to eliminate the issue?


--
   This communication is intended for the use of the recipient to whom it
   is addressed, and may contain confidential, personal, and or privileged
   information. Please contact us immediately if you are not the intended
   recipient of this communication, and do not copy, distribute, or take
   action relying on it. Any communications received in error, or
   subsequent reply, should be deleted or destroyed.
---
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux





[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux