I don't have a suggested solution for this one, sorry. /etc/cron.d/raid-check is installed by mdadm, and runs /usr/sbin/raid-check , which doesn't actually work because this line: echo "${check[$dev]}" > /sys/block/$dev/md/sync_action errors out like so: /usr/sbin/raid-check: line 73: echo: write error: Permission denied The first time, the AVC looked like this: type=AVC msg=audit(1314594121.384:52772): avc: denied { write } for pid=21290 comm="sh" name="sync_action" dev=sysfs ino=16676 sc ontext=system_u:system_r:system_cronjob_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sysfs_t:s0 tclass=file but fixing that made it do this: type=AVC msg=audit(1314644521.916:66507): avc: denied { sys_admin } for pid=10248 comm="sh" capability=21 scontext=system_u:syst em_r:system_cronjob_t:s0-s0:c0.c1023 tcontext=system_u:system_r:system_cronjob_t:s0-s0:c0.c1023 tclass=capability type=SYSCALL msg=audit(1314644521.916:66507): arch=c000003e syscall=1 success=no exit=-13 a0=1 a1=7f4b29b1f000 a2=6 a3=fffffffffffff ff0 items=0 ppid=10245 pid=10248 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=203 comm="sh" exe="/b in/bash" subj=system_u:system_r:system_cronjob_t:s0-s0:c0.c1023 key=(null) which I don't really know how to deal with. Weirdly, when I run it with "setenforce 0", all I get back is: type=AVC msg=audit(1314645901.549:68205): avc: denied { write } for pid=12139 comm="sh" name="sync_action" dev=sysfs ino=17060 scontext=system_u:system_r:system_cronjob_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sysfs_t:s0 tclass=file type=AVC msg=audit(1314645907.607:68218): avc: denied { setsched } for pid=12179 comm="renice" scontext=system_u:system_r:system_cronjob_t:s0-s0:c0.c1023 tcontext=system_u:system_r:kernel_t:s0 tclass=process So, not really sure what to do here, thought I'd pass it on for the clueful people to look at. -Robin
Did you disable the unconfined.pp module? Miroslav we probably should label raid-check as mdadm_exec_t and allow cron to transition to this domain. Fixed in selinux-policy-3.10.0-23.fc16
(In reply to comment #1) > Did you disable the unconfined.pp module? Erm, yes, I meant "can't run without unconfined". You can safely assume that all bugs I enter are with unconfined.pp disabled (in fact, removed entirely) because I have puppet enforcing that state every 15 minutes. :) rlpowell@basti> sudo sh -c "semodule -l | grep -i unc" unconfineduser 1.0.0 rlpowell@basti> I'm trying to help. :) -Robin
Great. You probably should just disable it since if you remove it a policy update will add it back, where as if it is disabled, it will stay disabled.
Probably, but puppet seems to remove by default, and I haven't cared enough to hunt that down inside puppet and fix it. -Robin
selinux-policy-3.9.16-39.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/selinux-policy-3.9.16-39.fc15
Package selinux-policy-3.9.16-39.fc15: * should fix your issue, * was pushed to the Fedora 15 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.9.16-39.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/selinux-policy-3.9.16-39.fc15 then log in and leave karma (feedback).
selinux-policy-3.9.16-39.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.