Bug 747662

Summary: SELinux blocks block-backed disks used with Xen unless specially configured
Product: [Fedora] Fedora Reporter: Kyle <redhatbugzilla>
Component: selinux-policyAssignee: Miroslav Grepl <mgrepl>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: unspecified    
Version: 16CC: dominick.grift, dwalsh, mgrepl
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-10-22 11:34:47 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Kyle 2011-10-20 16:45:19 UTC
Description of problem:
When starting a VM, Xen dies with "ERROR (XendBootloader:43) Disk isn't accessible" when using a block-backed disk and SELinux enforced

Version-Release number of selected component (if applicable):
F16 Beta

How reproducible:
Unknown. I'm going to try doing a fresh install of a VM tomorrow, see if that fixes it.

Steps to Reproduce:
1. Ensure SElinux is in enforcing mode
2. Start a VM (using xm create config.file or similar)
3. Watch it die
  
Actual results:
xm create prints an error ("Error: Disk isn't accessible") and dies

Expected results:
Xen VM comes up as per normal.

Additional info:
avc denial in dmesg:
[  887.378877] type=1400 audit(1319126448.379:25): avc:  denied  { read } for  pid=3168 comm="xend" name="dm-6" dev=devtmpfs ino=13634 scontext=system_u:system_r:xend_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file

This VM was created with virt-install under F15, so SELinux labels should have been set correctly. 
Also, http://fedoraproject.org/wiki/FedoraXenQuickstartFC6#SELinux (FC6 is ancient, I know) says "Block device backed disks are already labelled correctly to allow them to pass SELinux checks." which no longer seems to be the case.

Comment 1 Kyle 2011-10-22 11:34:47 UTC

*** This bug has been marked as a duplicate of bug 745996 ***