Description of problem: qemu-kvm based virtual machines can not read files labeled as public_content_t, although as their label suggest they should be public and readable by any process. If the the web, samba and NFS servers can read (and share) them, I don't see any reason to forbid KVM from reading them. I need this so that I can share the install ISO images with other people while using them for my virtual machines. Version-Release number of selected component (if applicable): selinux-policy-targeted-3.6.32-89.fc12.noarch.rpm
A related RFE is bug #568933.
Seems reasonable, but what is happening now? Is libvirt relabeling the image file when the virtual machine starts?
(In reply to comment #1) > A related RFE is bug #568933. Sorry, I meant bug #568935. (In reply to comment #2) > Seems reasonable, but what is happening now? Is libvirt relabeling the image > file when the virtual machine starts? Yes, libvirt is relabeling the image when the virtual machine starts.
Are you still seeing this problem? IE Is this fixed in the current release?
(In reply to comment #4) > Are you still seeing this problem? IE Is this fixed in the current release? libvirt-0.8.2-1.fc13.x86_64.rpm is still changing the label of ISO images to virt_content_t (from public_content_t).
I relabeled the ISO image to public_content_t after the virtual machine was started and I didn't see any complaints (ausearch --start recent => no matches).
(In reply to comment #5) > (In reply to comment #4) > > Are you still seeing this problem? IE Is this fixed in the current release? > > libvirt-0.8.2-1.fc13.x86_64.rpm is still changing the label of ISO images to > virt_content_t (from public_content_t). This is (maybe unwanted) behavior of libvirt (see #568935, as you've already mentioned). (In reply to comment #6) > I relabeled the ISO image to public_content_t after the virtual machine was > started and I didn't see any complaints (ausearch --start recent => no > matches). So the SELinux part is fixed, I'd say. Do you agree? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #7) > (In reply to comment #6) > > I relabeled the ISO image to public_content_t after the virtual machine was > > started and I didn't see any complaints (ausearch --start recent => no > > matches). > > So the SELinux part is fixed, I'd say. Do you agree? Yes, I think so. I'm not sure about this because I didn't know if SELinux policies are also enforced after a file is opened, e.g. open syscalls are checked, but what about read syscalls? Anyway I guess I could reopen this bug if I'll get SELinux denials after bug #568935 is fixed.
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping