I noticed my mrtg graphs weren't getting updated. They're done normally by /etc/cron.d/mrtg which looks like .. * * * * * root LANG=C LC_ALL=C /usr/bin/mrtg /etc/mrtg/mrtg.cfg --lock-file /var/lock/mrtg/mrtg_l --confcache-file /var/lib/mrtg/mrtg.ok Running that command by hand works fine. The graphs update. Looking in the logs, I see no mention of cron anywhere. crond is running. It wakes up once a minute, and does pretty much nothing... nanosleep({60, 0}, {60, 0}) = 0 time(NULL) = 1221158821 time(NULL) = 1221158821 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0 select(6, [5], NULL, NULL, {0, 0}) = 0 (Timeout) stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3519, ...}) = 0 time(NULL) = 1221158821 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigaction(SIGCHLD, NULL, {0x804a080, [], SA_RESTART}, 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
/var/log/cron: Sep 17 19:22:01 vmware188 crond[2060]: ((null)) Unauthorized SELinux context (/etc/crontab) Sep 17 19:22:01 vmware188 crond[2060]: ((null)) Unauthorized SELinux context (/etc/cron.d/mrtg) Sep 17 19:22:01 vmware188 crond[2060]: ((null)) Unauthorized SELinux context (/etc/cron.d/smolt) audit.log CROND subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:session_open acct="root" exe="/usr/sbin/crond" CRONTAB subj=unconfined_u:unconfined_r:unconfined_crontab_t:s0-s0:c0.c1023 msg='op=PAM:accounting acct="root" exe="/usr/bin/crontab" The jobs created in 'crontab -e' are working.
setting blocker for beta... if that is too hardline change to F10Blocker, but seems like we would want this working in beta.
I believe this is a problem with cron. Looks like it is choosing the wrong context?
Never mind, it is mine. Fixed in selinux-policy-3.5.8-6.fc10
*** Bug 466018 has been marked as a duplicate of this bug. ***
It's probably still problem, see #466018
Dave are you still seeing the invalid context error?
no. I don't think I ever did see the errors Marcela points out above.
Are the jobs running in permissive mode.
I just noticed this in the cron log file which might explain it.. Oct 8 17:40:42 firewall crond[13870]: (root) BAD FILE MODE (/etc/cron.d/mrtg) for some reason, that file had gained an +x bit. Removing it seems to have solved this bug.
I'm getting this right now in F11, with cronie-1.3-2.fc11.x86_64 selinux-policy-3.6.12-62.fc11.noarch in enforcing mode: Jul 27 09:05:37 ws crond[15782]: (CRON) STARTUP (1.3) Jul 27 09:05:37 ws crond[15782]: ((null)) Unauthorized SELinux context (/etc/crontab) Jul 27 09:05:37 ws crond[15782]: ((null)) Unauthorized SELinux context (/etc/cron.d/clamav-update) Jul 27 09:05:37 ws crond[15782]: ((null)) Unauthorized SELinux context (/etc/cron.d/0hourly) Jul 27 09:05:37 ws crond[15782]: ((null)) Unauthorized SELinux context (/etc/cron.d/smolt) Jul 27 09:05:37 ws crond[15782]: (CRON) INFO (running with inotify support) Jul 27 09:05:37 ws crond[15782]: (CRON) INFO (@reboot jobs will be run at computer's startup.)
Are you seeing any AVC messages in /var/log/audit/audit.log?
Sorry for the delay, No, I don't see any avc messages in audit.log. Do you need any other info? Aug 9 18:16:54 ws crond[5592]: (CRON) STARTUP (1.3) Aug 9 18:16:54 ws crond[5592]: ((null)) Unauthorized SELinux context (/etc/crontab) Aug 9 18:16:54 ws crond[5592]: ((null)) Unauthorized SELinux context (/etc/cron.d/clamav-update) Aug 9 18:16:54 ws crond[5592]: ((null)) Unauthorized SELinux context (/etc/cron.d/0hourly) Aug 9 18:16:54 ws crond[5592]: ((null)) Unauthorized SELinux context (/etc/cron.d/smolt) Aug 9 18:16:54 ws crond[5592]: (CRON) INFO (running with inotify support) Aug 9 18:16:54 ws crond[5592]: (CRON) INFO (@reboot jobs will be run at computer's startup.) Aug 9 18:17:09 ws crond[5618]: (CRON) STARTUP (1.3) Aug 9 18:17:09 ws crond[5618]: ((null)) Unauthorized SELinux context, but SELinux in permissive mode, continuing (/etc/crontab) Aug 9 18:17:09 ws crond[5618]: ((null)) Unauthorized SELinux context, but SELinux in permissive mode, continuing (/etc/cron.d/clamav-update) Aug 9 18:17:09 ws crond[5618]: ((null)) Unauthorized SELinux context, but SELinux in permissive mode, continuing (/etc/cron.d/0hourly) Aug 9 18:17:09 ws crond[5618]: ((null)) Unauthorized SELinux context, but SELinux in permissive mode, continuing (/etc/cron.d/smolt) Aug 9 18:17:09 ws crond[5618]: (CRON) INFO (running with inotify support) Aug 9 18:17:09 ws crond[5618]: (CRON) INFO (@reboot jobs will be run at computer's startup.) root@ws audit # ls -Z /etc/crontab /etc/cron.d/clamav-update /etc/cron.d/0hourly /etc/cron.d/smolt -rw-r--r--. root root system_u:object_r:system_cron_spool_t:s0 /etc/cron.d/0hourly -rw-------. root root system_u:object_r:system_cron_spool_t:s0 /etc/cron.d/clamav-update -rw-r--r--. root root system_u:object_r:system_cron_spool_t:s0 /etc/cron.d/smolt -rw-r--r--. root root system_u:object_r:system_cron_spool_t:s0 /etc/crontab
What does the output of the following two commands show semanage user -l semanage login -l
nico@ws ~ $ sudo semanage user -l [sudo] password for nico: Labeling MLS/ MLS/ SELinux User Prefix MCS Level MCS Range SELinux Roles 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 sysadm_u user s0 s0-s0:c0.c1023 sysadm_r system_u user s0 s0-s0:c0.c1023 system_r user_u user s0 s0 user_r xguest_u user s0 s0 xguest_r nico@ws ~ $ sudo semanage login -l Login Name SELinux User MLS/MCS Range __default__ unconfined_u s0 emilio user_u s0 root unconfined_u s0-s0:c0.c1023 system_u system_u s0-s0:c0.c1023 tunnel guest_u s0
Ok, what about ps -eZ | grep cron
nico@ws ~ $ ps -eZ|grep cron system_u:system_r:crond_t:s0-s0:c0.c1023 2908 ? 00:00:00 atd unconfined_u:system_r:crond_t:s0-s0:c0.c1023 5618 ? 00:00:00 crond nico@ws ~ $
Steve, Any ideas?
Why isn't there an entry for unconfined_u in his semanage user -l output? And why is his crond running in unconfined_u rather than system_u (likely restarted by hand; try restarting via run_init)?
I have no idea why there's no unconfined_u in user -l. I have it on my F11 box at home. They both have selinux-policy-targeted-3.6.12-69.fc11.noarch selinux-policy-3.6.12-69.fc11.noarch I restarted crond with run_init: root@ws targeted # ps -efZ |grep cron system_u:system_r:crond_t:s0-s0:c0.c1023 root 2908 1 0 Aug09 ? 00:00:00 /usr/sbin/atd system_u:system_r:crond_t:s0-s0:c0.c1023 root 16654 1 0 20:15 ? 00:00:00 crond Same logs: Aug 10 20:15:41 ws crond[16654]: (CRON) STARTUP (1.3) Aug 10 20:15:41 ws crond[16654]: ((null)) Unauthorized SELinux context, but SELinux in permissive mode, continuing (/etc/crontab) Aug 10 20:15:41 ws crond[16654]: ((null)) Unauthorized SELinux context, but SELinux in permissive mode, continuing (/etc/cron.d/clamav-update) Aug 10 20:15:41 ws crond[16654]: ((null)) Unauthorized SELinux context, but SELinux in permissive mode, continuing (/etc/cron.d/0hourly) Aug 10 20:15:41 ws crond[16654]: ((null)) Unauthorized SELinux context, but SELinux in permissive mode, continuing (/etc/cron.d/smolt) Aug 10 20:15:41 ws crond[16654]: (CRON) INFO (running with inotify support) Aug 10 20:15:41 ws crond[16654]: (CRON) INFO (@reboot jobs will be run at computer's startup.)
semodule -l | grep unconfined
On the machine with the problem: root@ws targeted # semodule -l |grep unconfined unconfined 3.0.1 On the machine without the problem: root@santa ~ # semodule -l |grep unconfined unconfined 3.0.1 unconfineduser 1.0.0
semodule -i /usr/share/selinux/targeted/unconfineduser.pp.bz2 There was an upgrade problem during the Beta on F11, that could have caused this.
Yes indeed I remember having had issues after upgrade. Unfortunately your command fails, something fishy in file_contexts: # semodule -i /usr/share/selinux/targeted/unconfineduser.pp.bz2 /etc/selinux/targeted/contexts/files/file_contexts: Multiple different specifications for /var/spool/MailScanner(/.*)? (system_u:object_r:mailscanner_spool_t:s0 and system_u:object_r:clamd_var_run_t:s0). /etc/selinux/targeted/contexts/files/file_contexts: Invalid argument libsemanage.semanage_install_active: setfiles returned error code 1. /etc/selinux/targeted/contexts/files/file_contexts: Multiple different specifications for /var/spool/MailScanner(/.*)? (system_u:object_r:mailscanner_spool_t:s0 and system_u:object_r:clamd_var_run_t:s0). /etc/selinux/targeted/contexts/files/file_contexts: Invalid argument libsemanage.semanage_install_active: setfiles returned error code 1. semodule: Failed! Any idea how to fix that? I tried removing the offending line by hand, or with semanage, but it fails.
Something went very wrong on your update. Try this # setenforce 0 # rm -rf /etc/selinux/targeted # yum -y reinstall selinux-policy-targeted # restorecon -R -v /etc/selinux # setenforce 1 Should fix your system.
Actually yum -y reinstall selinux-policy\* Should be the correct thing to do.
Did this fix your problem?
Yes this appears to have fixed it, thank you.