Description of problem: Really bizarre problem. qemu-system-x86_64 cannot start up (only when run from libvirtd, I can start it manually). The error is: /usr/bin/qemu-system-x86_64: error while loading shared libraries: libjson-c.so.2: cannot open shared object file: Permission denied This is caused by an SELinux AVC: time->Wed Apr 16 23:26:18 2014 type=SYSCALL msg=audit(1397705178.402:464): arch=c000003e syscall=2 success=no exit=-13 a0=7fffeab2a820 a1=80000 a2=7f04f89d34d0 a3=ffffffff items=0 ppid=1 pid=1168 auid=4294967295 uid=107 gid=107 euid=107 suid=107 fsuid=107 egid=107 sgid=107 fsgid=107 ses=4294967295 tty=(none) comm="qemu-system-x86" exe="/usr/bin/qemu-system-x86_64" subj=system_u:system_r:svirt_t:s0:c541,c842 key=(null) type=AVC msg=audit(1397705178.402:464): avc: denied { read } for pid=1168 comm="qemu-system-x86" name="libjson-c.so.2" dev="sda3" ino=1151 scontext=system_u:system_r:svirt_t:s0:c541,c842 tcontext=system_u:object_r:file_t:s0 tclass=lnk_file audit2allow suggests: #============= svirt_t ============== allow svirt_t file_t:lnk_file read; $ ls -lZ /usr/lib64/libjson-c.so.2* lrwxrwxrwx. root root system_u:object_r:file_t:s0 /usr/lib64/libjson-c.so.2 -> libjson-c.so.2.0.1 -rwxr-xr-x. root root system_u:object_r:file_t:s0 /usr/lib64/libjson-c.so.2.0.1 Version-Release number of selected component (if applicable): selinux-policy-3.12.1-149.fc20.noarch libvirt-daemon-kvm-1.1.3.4-4.fc20.x86_64 json-c-0.11-3.fc20.x86_64 How reproducible: 100% Steps to Reproduce: 1. Try to run an x86-64 guest using libvirt.
Hi, Use restorecon to fit it: "# restorecon -v /usr/lib64/libjson-c.so.2*"
Maybe you will need to fix labeling on your system at all. Could you try to execute # restorecon -Rv /usr/lib64 to see if there is more file_t issues.
I did the restorecon before sending the bug report -- it was the first thing I thought of. It didn't fix it however. Unfortunately I didn't note down the output of the restorecon command -- I just let it run, rebooted, and retested. Are the file_t labels on /usr/lib64 files wrong? And if so, where would they come from?
I'm on holiday now until Tuesday. Setting NEEDINFO of me to rerun restorecon and check the output.
You need to run # restorecon -Rv /usr/lib64 to fix labeling on links in this directory. Have you had disabled SELinux? file_t means no SELinux label.
OK, strange. restorecon (run a second time) did restore the label on the file correctly.(In reply to Miroslav Grepl from comment #5) > Have you had disabled SELinux? Permissive yes, Disabled no.
RIchard did you mv a file off of a disk attached to the system. file_t means the object did not have a label on it. Which means it was either created on a new file system without labels or mv'd into place from a file system without labels.
BTW When you move to Rawhide you can alias mv to mv -Z and then mv will automatically set labels correctly on the destination file.