Bug 1639381
Summary: | Drop the selinux domain check or use system_cronjob_t domain for the system crontab files | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Lukas Vrabec <lvrabec> |
Component: | cronie | Assignee: | Tomas Mraz <tmraz> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 29 | CC: | awilliam, bcotton, bojan, dan, dwalsh, extras-qa, fidencio, gmarr, jmontleo, jsullivan3, kparal, lvrabec, mailings, mgrepl, mmaslano, nphilipp, plambri, plautrba, pmarciniak, rmy, robatino, robin.bjorklin, tmraz |
Target Milestone: | --- | Keywords: | CommonBugs, Triaged |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | https://fedoraproject.org/wiki/Common_F29_bugs#crond-selinux RejectedBlocker AcceptedFreezeException PrioritizedBug | ||
Fixed In Version: | cronie-1.5.2-3.fc29 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | 1625645 | Environment: | |
Last Closed: | 2018-11-03 00:01:38 UTC | Type: | Bug |
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: | 1625645 | ||
Bug Blocks: | 1517014 |
Description
Lukas Vrabec
2018-10-15 15:22:32 UTC
So, the selinux part has been closed. Does that mean the issue is fixed? The symptoms are fixed however a proper fix requires modification of cronie otherwise further changes in SELinux policy could again regress this. This can be done after F29 is released. (In reply to Tomas Mraz from comment #2) > The symptoms are fixed however a proper fix requires modification of cronie > otherwise further changes in SELinux policy could again regress this. > > This can be done after F29 is released. OK, thanks for the info. I'm asking from a purely practical perspective, because cron jobs that won't run is a major problem for anyone running Fedora on a server (myself included). As noted in bug 1625645, the symptoms are still present in an updated version of Fedora 29 Beta: cron jobs simply do not run in my Fedora 29 Beta installations without the workaround described in comment 12. Output of 'rpm -qa | grep selinux | sort': container-selinux-2.74-1.gita62c2db.fc29.noarch libselinux-2.8-4.fc29.x86_64 libselinux-utils-2.8-4.fc29.x86_64 python2-libselinux-2.8-4.fc29.x86_64 python3-libselinux-2.8-4.fc29.x86_64 rpm-plugin-selinux-4.14.2-1.fc29.x86_64 selinux-policy-3.14.2-40.fc29.noarch selinux-policy-devel-3.14.2-40.fc29.noarch selinux-policy-targeted-3.14.2-40.fc29.noarch Output of 'rpm -qa | grep cron | sort': cronie-1.5.2-2.fc29.x86_64 cronie-anacron-1.5.2-2.fc29.x86_64 crontabs-1.11-17.20150630git.fc29.noarch Output of 'ps -efZ | grep cron system_u:system_r:crond_t:s0-s0:c0.c1023 root 1574 1 0 Oct26 ? 00:00:00 /usr/sbin/atd -f system_u:system_r:crond_t:s0-s0:c0.c1023 root 10745 1 0 14:13 ? 00:00:00 /usr/sbin/crond -n unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 10871 9441 0 14:17 pts/0 00:00:00 grep --color=auto cron After issuing "systemctl restart crond" the output of 'systemctl status crond --no-pager -l': ● crond.service - Command Scheduler Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled; vendor preset: enabled) Active: active (running) since Sat 2018-10-27 14:19:29 EDT; 9s ago Main PID: 11002 (crond) Tasks: 1 (limit: 1148) Memory: 616.0K CGroup: /system.slice/crond.service └─11002 /usr/sbin/crond -n Oct 27 14:19:29 test-rivendell crond[11002]: ((null)) Unauthorized SELinux context=system_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 file_context=system_u:object_r:system_cron_spool_t:s0 (/etc/cron.d/0hourly) Oct 27 14:19:29 test-rivendell crond[11002]: (root) FAILED (loading cron table) Oct 27 14:19:29 test-rivendell crond[11002]: ((null)) Unauthorized SELinux context=system_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 file_context=system_u:object_r:system_cron_spool_t:s0 (/etc/cron.d/raid-check) Oct 27 14:19:29 test-rivendell crond[11002]: (root) FAILED (loading cron table) Oct 27 14:19:29 test-rivendell crond[11002]: ((null)) Unauthorized SELinux context=system_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 file_context=system_u:object_r:system_cron_spool_t:s0 (/etc/cron.d/clamav-update) Oct 27 14:19:29 test-rivendell crond[11002]: (root) FAILED (loading cron table) Oct 27 14:19:29 test-rivendell crond[11002]: ((null)) Unauthorized SELinux context=system_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 file_context=system_u:object_r:system_cron_spool_t:s0 (/etc/cron.d/rsnapshot) Oct 27 14:19:29 test-rivendell crond[11002]: (root) FAILED (loading cron table) Oct 27 14:19:29 test-rivendell crond[11002]: (CRON) INFO (running with inotify support) Oct 27 14:19:29 test-rivendell crond[11002]: (CRON) INFO (@reboot jobs will be run at computer's startup.) Sorry - that's bug 1625645 comment 12... (In reply to Tomas Mraz from comment #2) > The symptoms are fixed however a proper fix requires modification of cronie > otherwise further changes in SELinux policy could again regress this. > > This can be done after F29 is released. Definitely untrue. I can confirm that cron jobs from /etc/cron.d are definitely not running on F29 final (with all the testing updates applied as well). Example: Oct 27 09:25:53 <system> crond[904]: ((null)) Unauthorized SELinux context=system_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 file_context=system_u:object_r:system_cron_spool_t:s0 (/etc/cron.d/clamav-update) This should have been a blocker. A bit too late now, but let's hope it gets fixed soon. Otherwise, everyone and their dog is going to pile on here... Can confirm that crond only loads tabs after applying the workaround linked from comment #5 -- https://bugzilla.redhat.com/show_bug.cgi?id=1625645#c12 cronie-1.5.2-3.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-fade853384 *** Bug 1625645 has been marked as a duplicate of this bug. *** cronie-1.5.2-3.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-fade853384 The fix is looking good to me in my environment. I removed the workaround listed earlier. Output of 'rpm -qa | grep cron | sort': cronie-1.5.2-3.fc29.x86_64 cronie-anacron-1.5.2-3.fc29.x86_64 crontabs-1.11-17.20150630git.fc29.noarch Output of 'ps -efZ | grep cron system_u:system_r:crond_t:s0-s0:c0.c1023 root 1121 1 0 20:22 ? 00:00:00 /usr/sbin/atd -f system_u:system_r:crond_t:s0-s0:c0.c1023 root 1135 1 0 20:22 ? 00:00:00 /usr/sbin/crond -n unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 7696 1704 0 20:31 pts/1 00:00:00 grep --color=auto cron Output of 'systemctl status crond --no-pager': ● crond.service - Command Scheduler Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2018-11-01 20:22:29 EDT; 4min 29s ago Main PID: 1135 (crond) Tasks: 1 (limit: 2358) Memory: 1.1M CGroup: /system.slice/crond.service └─1135 /usr/sbin/crond -n Nov 01 20:22:29 localhost.localdomain systemd[1]: Started Command Scheduler. Nov 01 20:22:29 localhost.localdomain crond[1135]: (CRON) STARTUP (1.5.2) Nov 01 20:22:29 localhost.localdomain crond[1135]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 79% if used.) Nov 01 20:22:29 localhost.localdomain crond[1135]: (CRON) INFO (running with inotify support) Test cron job: echo "* * * * * root date >> /tmp/cronstuffs.txt" > /etc/cron.d/test And we have output from 'tail /tmp/cronstuffs.txt': Thu Nov 1 20:31:01 EDT 2018 Thu Nov 1 20:32:01 EDT 2018 Thank you! *** Bug 1645300 has been marked as a duplicate of this bug. *** cronie-1.5.2-3.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report. *** Bug 1645825 has been marked as a duplicate of this bug. *** |