Bug 736530 - mdadm fails to auto-start md arrays on f16-beta.tc1 live media due to avc denials
mdadm fails to auto-start md arrays on f16-beta.tc1 live media due to avc den...
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Miroslav Grepl
Fedora Extras Quality Assurance
Depends On:
Blocks: 731177
  Show dependency treegraph
Reported: 2011-09-07 19:32 EDT by David Lehman
Modified: 2011-09-15 11:14 EDT (History)
12 users (show)

See Also:
Fixed In Version: selinux-policy-3.10.0-28.fc16
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 731177
Last Closed: 2011-09-15 11:14:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
syslog from f16-beta.tc1 livecd showing failure (95.34 KB, application/octet-stream)
2011-09-07 19:32 EDT, David Lehman
no flags Details

  None (edit)
Description David Lehman 2011-09-07 19:32:27 EDT
Created attachment 522019 [details]
syslog from f16-beta.tc1 livecd showing failure

--- Additional comment from dlehman@redhat.com on 2011-09-07 19:26:59 EDT ---

The live version's problem is related to selinux. Here are the syslog entries from mdadm trying to start the array:

Sep  7 19:12:34 localhost kernel: [   36.687948] type=1400 audit(1315437142.158:4): avc:  denied  { create } for  pid=555 comm="mdadm" name="0" scontext=system_u:system_r:mdadm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:mdadm_var_run_t:s0 tclass=lnk_file
Sep  7 19:12:34 localhost kernel: [   37.686153] md: bind<sda5>
Sep  7 19:12:34 localhost kernel: [   37.874116] md: bind<sda4>
Sep  7 19:12:34 localhost kernel: [   37.900842] type=1400 audit(1315437143.371:5): avc:  denied  { module_request } for  pid=556 comm="mdadm" kmod="md-level-1" scontext=system_u:system_r:mdadm_t:s0-s0:c0.c1023 tcontext=system_u:system_r:kernel_t:s0 tclass=system
Sep  7 19:12:34 localhost kernel: [   37.910393] bio: create slab <bio-1> at 1
Sep  7 19:12:34 localhost kernel: [   37.938256] md: personality for level 1 is not loaded!

It is failing to create a symlink somewhere in /var/run and then it is failing to load the md raid1 kernel module, both times thwarted by selinux.
Comment 1 Adam Williamson 2011-09-08 12:44:22 EDT
note that this is a Beta blocker bug through 731177's dependence on it, so please prioritize - thanks!
Comment 2 Doug Ledford 2011-09-08 20:23:27 EDT
Dan, were the SELinux rules for mdadm updated to account for the change from /var/run to /run (and will they still work if the final file location is in /run instead of /var/run)?  I can build a new mdadm that uses /run directly instead of going through /var/run, but I'm not certain that will solve this problem is what's happening is that the old mdadm rules expect /var/run, but due to the /var/run->/run symlink the final real file names are ended up in /run/mdadm and not matching the rules.
Comment 3 Daniel Walsh 2011-09-12 15:38:07 EDT
Yes we are labeling everything under /run as if it was under /var/run.  We don't care how you create your files.

Miroslav lets add

Comment 4 Daniel Walsh 2011-09-12 15:38:39 EDT
Should probably backport to RHEL6 also.
Comment 5 Adam Williamson 2011-09-13 15:43:56 EDT
Dan, Miroslav: this is a blocker issue for F16 Beta and we need all blockers resolved today or tomorrow in order to compose the first Beta release candidate on time. Can you please fix this and submit an updated selinux-policy as an update ASAP? Thanks!
Comment 6 Miroslav Grepl 2011-09-13 16:04:05 EDT
This is fixed in the latest build.


- Allow collectd to read hardware state information 
- Add loop_control_device_t 
- Allow mdadm to request kernel to load module 

Do I need to do a new update on F16 with this policy release? Or is the build enough?
Comment 7 Miroslav Grepl 2011-09-13 16:09:45 EDT
Actually I am going to do a new build right now which should be included in the compose and submit it as an update.
Comment 8 Adam Williamson 2011-09-13 16:10:21 EDT
yes, please submit an update - thanks!
Comment 9 Fedora Update System 2011-09-13 16:41:39 EDT
selinux-policy-3.10.0-28.fc16 has been submitted as an update for Fedora 16.
Comment 10 Fedora Update System 2011-09-13 18:20:40 EDT
Package selinux-policy-3.10.0-28.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing selinux-policy-3.10.0-28.fc16'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
Comment 11 Adam Williamson 2011-09-13 21:10:01 EDT
I can confirm the fix looks good. I built a live image with anaconda 16.17 and selinux-policy 3.10.0-28. I do not see this traceback on the console when starting liveinst, and I can select my BIOS RAID array in advanced devices and 'continue': previously, anaconda would exit showing the traceback at that point, now it continues.

I can't complete a test install as the RAID array is my production laptop F15 install, but at least I can say this specific issue looks to be fixed.
Comment 12 Fedora Update System 2011-09-15 11:13:35 EDT
selinux-policy-3.10.0-28.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.