Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I'm running Fedora 17 with KVM and the virtual machine runs okay. I tried to follow this to get access to a file on the host system but SELinux prevents the VM from accessing any files other than those in /var/lib/libvirt/images. This is the message the host gives when running ls inside the VM on the shared path.

SELinux is preventing /usr/bin/qemu-kvm from read access on the
directory share.

How can I get around this? The purpose of my VM is to test binaries on multiple Linux distributions so a shared path would be easiest. Is there a way to make /tmp/share absolutely accessible by everyone?

share|improve this question
    
Besides changing the file context (which is ultimately the best answer) you can either switch SELinux to permissive (if you're not serving to the broader network I mean), or do an audit2allow which will automatically generate the SELinux policy changes that will allow the operations currently being denied. –  Joel Davis Jun 12 '13 at 1:02

1 Answer 1

The destination share (you didn't give the path qemu is trying to access) should have the svirt_image_t security context (can be verified by doing ls -ldZ <pathToDestination>). If this is labelled as something else SELinux will not let kvm read/write on that dir.

Solution is to do the following (replace <pathToDestination> with the actual path):

semanage fcontext -a -t svirt_image_t "/<pathToDestination>(/.*)?"
restorecon -vR <pathToDestination>

The above sets the default file context for anything under and including pathToDestination, the second command tells SELinux to restore file contexts on everything underneath that directory to what we have as being the default (i.e what semanage changes).

You can also check /var/log/audit/audit.log for possible reason for the AVC denial

Search for the AVC denials of today /sbin/ausearch -m avc -ts today

Or check /var/log/messages It will tell you the unique identifier for the AVC denial which needs to be run as an argument to sealert -l

Example: sealert -l 84e0b04d-d0ad-4347-8317-22e74f6cd020

You have to go through that information. It tells the commands you need to execute to overcome AVC denials.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.