Bug 461988
| Summary: | cron.d entries aren't getting run. | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Dave Jones <davej> |
| Component: | selinux-policy | Assignee: | Daniel Walsh <dwalsh> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 11 | CC: | dwalsh, mgrepl, mmaslano, nicolas.monnet, pertusus, pfrields, sdsmall, tmraz |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-09-06 19:20:21 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: | |||
| Bug Depends On: | |||
| Bug Blocks: | 446447 | ||
/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. |
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