Description of problem: virt-manager aborting at virDomainCreateLinux() due to selinux access denial (AVC denied). Here are the summary of the 2 AVC denied messages: 1. SELinux is preventing /usr/sbin/tapdisk (xend_t) "read" to img (xen_image_t). 2. SELinux is preventing /usr/sbin/tapdisk (xend_t) "read" to img (xen_image_t). Version-Release number of selected component (if applicable): virt-manager 0.3.2-1.fc7 xen 3.0.4-9.fc7 selinux-policy 2.5.9-5.fc7 How reproducible: persistent Steps to Reproduce: 1. run xen environment 2. executie virt-manager 3. sample source install tree: http://192.168.3.102/a/fed/x86_64/os sample image: /var/lib/xen/images/img/v41f2.i NOTE linked directory: /var/lib/xen/images/img -> /a/img Actual results: virt-manager console display of error message: ERROR: virDomainCreateLinux() failed POST operation failed: (xend.err 'Device 0 (vif) could not be connected. Hotplug scripts not working.')
Created attachment 150837 [details] output of AVC denied {tapdisk}
Created attachment 150838 [details] AVC denied output: xen-hotplug-cle (udev_t)
Created attachment 150839 [details] AVC denied output: xen read to config.sxp
In the future please add three different Bugzilla's and attach them to the package not to SELinux, and cc me if you would. The first one is a bug in policy, which should allow xend to read symbolic links labeled xen_device_t. The second one I am not sure why udev would want to read xend_log_t. The third bugzilla looks like a mislabeled config.sxp. This should not be labeled tmp_t. Running restorecon config.sxp would probably fix. Not sure what this file is and how it was created but if it was created in /tmp and then mv'd somewhere it could have the wrong context on it.
"The second one I am not sure why udev would want to read xend_log_t." I'm not sure either but I saw a machine yesterday where all sorts of scripts under /etc/xen/scripts (all labeled bin_t) were being called and running in the udev_t domain. A search of ps -efZ | grep udev only showed one process running as udev_t (udev) does udev new call xen scripts for some reason and didn't used to?
Fixed in selinux-policy-2.5.11-8.fc7
Should be fixed in the current release