Bug 124533 - Execution of run-parts cron entries fails with selinux enabled
Summary: Execution of run-parts cron entries fails with selinux enabled
Alias: None
Product: Fedora
Classification: Fedora
Component: crontabs   
(Show other bugs)
Version: 2
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jason Vas Dias
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2004-05-27 10:38 UTC by Fritz Elfert
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-08-03 23:13:59 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Fritz Elfert 2004-05-27 10:38:59 UTC
Description of problem:
With selinux enabled in enforcing mode, i get an hourly mail with the
following text:

Subject: Cron <root@hsi-kbw-082-212-008-128> run-parts /etc/cron.hourly

execl: couldn't exec `/bin/bash'
execl: Permission denied

The corresponding error in /var/log/messages is:

kernel: audit(1085652060.469:0): avc:  denied  { transition } for
pid=11218 exe=/usr/sbin/crond path=/bin/bash dev=hda2 ino=883049
context=root:system_r:crond_t tcontext=user_u:sysadm_r:sysadm_t

Same happens fro cron.daily etc.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Enable selinux in enforcing mode
Actual results:
cron run-parts entries do not run.

Expected results:
cron run-parts should run.

Additional info:
I don't know, if crontabs is the right package to report this against
but as far as i understand, the necessary policy entries for some
functionality are supposed to be adapted/installed by the rpm
providing this functionality.

Comment 1 Fritz Elfert 2004-05-27 17:37:26 UTC
Meanwhile i found out, that this error only happens when
root:sysadm_r:sysadm_t restarts crond manually with "service crond
restart". (Had done this because of a change in the systems time
setup). It works well, when crond is started during boot from within
the initrc context.

-> lowered the severity as this happens not very often.


Comment 2 Fritz Elfert 2004-05-27 18:06:29 UTC
Just got the following hint:

So there should probably be some similar functionality be added to
/etc/rc.d/init.d/crond or even in a more generic fashion to the
daemon() function in /etc/rc.d/init.d/functions ...


Comment 3 Jason Vas Dias 2004-08-03 23:13:59 UTC
Not happening when 'targetted' policy is in 'enforced' mode.
The correct transition has been added to the targetted policy;
administrators would need decide whether to customize the 
'strict' policy in the same way. 
Hence this bug is being closed.

Note You need to log in before you can comment on or make changes to this bug.