Description of problem: Restarting crond via "/etc/init.d/crond restart" succeeds without error, but "Unauthorized SELinux context" is reported in /var/log/cron and cronjobs do not run. This happens when SELinux boolean allow_execmod == 0. Version-Release number of selected component (if applicable): * cronie-1.4.5-2.fc14 * selinux-policy-3.9.7-12.fc14.noarch * selinux-policy-targeted-3.9.7-12.fc14.noarch How reproducible: Set allow_execmod=0 and restart crond. Steps to Reproduce: 1. /usr/sbin/setsebool allow_execmod=0 2. /etc/init.d/crond restart Actual results: Unauthorized context errors in /var/log/cron, cronjobs do not run. Expected results: No errors. Additional info: $ id -Z unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 $ /usr/sbin/getsebool allow_execmod allow_execmod --> off $ /etc/init.d/crond restart Stopping crond: [ OK ] Starting crond: [ OK ] $ tail /var/log/cron [...] Dec 1 05:11:37 localhost crond[17262]: (CRON) STARTUP (1.4.5) Dec 1 05:11:37 localhost crond[17262]: ((null)) Unauthorized SELinux context (/etc/crontab) Dec 1 05:11:38 localhost crond[17262]: ((null)) Unauthorized SELinux context (/etc/cron.d/0hourly) Dec 1 05:11:38 localhost crond[17262]: (root) Unauthorized SELinux context (/var/spool/cron/root) Dec 1 05:11:38 localhost crond[17262]: (CRON) INFO (running with inotify support) Dec 1 05:11:38 localhost crond[17262]: (CRON) INFO (@reboot jobs will be run at computer's startup.) $ /usr/sbin/setsebool allow_execmod=1 $ /usr/sbin/getsebool allow_execmod allow_execmod --> on $ /etc/init.d/crond restart Stopping crond: [ OK ] Starting crond: [ OK ] $ tail /var/log/cron Dec 1 05:11:37 localhost crond[17262]: (CRON) STARTUP (1.4.5) Dec 1 05:11:37 localhost crond[17262]: ((null)) Unauthorized SELinux context (/etc/crontab) Dec 1 05:11:38 localhost crond[17262]: ((null)) Unauthorized SELinux context (/etc/cron.d/0hourly) Dec 1 05:11:38 localhost crond[17262]: (root) Unauthorized SELinux context (/var/spool/cron/root) Dec 1 05:11:38 localhost crond[17262]: (CRON) INFO (running with inotify support) Dec 1 05:11:38 localhost crond[17262]: (CRON) INFO (@reboot jobs will be run at computer's startup.) Dec 1 05:12:12 localhost crond[17301]: (CRON) STARTUP (1.4.5) Dec 1 05:12:12 localhost crond[17301]: (CRON) INFO (running with inotify support) Dec 1 05:12:12 localhost crond[17301]: (CRON) INFO (@reboot jobs will be run at computer's startup.) $ There was bug #657104 mentioning the same symptoms and a workaround: rm -rf /etc/selinux/targeted && yum reinstall selinux-policy\* && /sbin/restorecon -rFv /etc/selinux && fixfiles onboot. That workaround helps as long as allow_execmod stays untouched. And for completeness: relabeling filesystem does not help. Is this expected behaviour (cronie depends on allow_execmod == 1) or a bug?
This looks like a bug in the selinux-policy. I can reproduce it here on fully up-to-date F14 as well.
So cron jobs stop working unless allow_execmod is turned on? Or are you seeing these errors in the log file no matter what?
The errors are there only if allow_execmod is turned off. And consequently the jobs stop to be executed.
Also allow_execmod==1 seems to be the default on F14, is that intentional?
Yes. Are you seeing any execmod errors in the log files when it is turned off?
No, but I m running a really minimal install of F14.
If you setenforce 0, does it work? What context is cron running with ps -eZ | grep cron
No, setenforce 0 does not remove the message: Dec 1 16:28:40 f14 crond[4661]: ((null)) Unauthorized SELinux context, but SELinux in permissive mode, continuing (/etc/crontab) Dec 1 16:28:40 f14 crond[4661]: ((null)) Unauthorized SELinux context, but SELinux in permissive mode, continuing (/etc/cron.d/0hourly) The crond is running with: unconfined_u:system_r:crond_t:s0-s0:c0.c1023
What does this show? semanage login -l semanage user -l
[root@f14 ~]# semanage login -l Login Name SELinux User MLS/MCS Range __default__ unconfined_u s0-s0:c0.c1023 root unconfined_u s0-s0:c0.c1023 system_u system_u s0-s0:c0.c1023 [root@f14 ~]# semanage user -l Labeling MLS/ MLS/ SELinux User Prefix MCS Level MCS Range SELinux Roles git_shell_u user s0 s0 git_shell_r guest_u user s0 s0 guest_r root user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_r staff_u user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_r sysadm_u user s0 s0-s0:c0.c1023 sysadm_r system_u user s0 s0-s0:c0.c1023 system_r unconfined_r unconfined_u user s0 s0-s0:c0.c1023 system_r unconfined_r user_u user s0 s0 user_r xguest_u user s0 s0 xguest_r
For some reason this has been removed from upstream. I do not remember why, and should probably be added back. ifdef(`enable_mcs',` init_ranged_daemon_domain(crond_t, crond_exec_t, s0 - mcs_systemhigh) ')
We have found a bug. *** This bug has been marked as a duplicate of bug 663331 ***