Bug 240665 - selinux errors after updating sysstat and vixie-cron
Summary: selinux errors after updating sysstat and vixie-cron
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: selinux-policy   
(Show other bugs)
Version: 4.5
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Daniel Walsh
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2007-05-19 17:51 UTC by Jason Corley
Modified: 2007-11-17 01:14 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-06-21 13:28:27 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 Jason Corley 2007-05-19 17:51:54 UTC
Description of problem:

After updating to sysstat-5.0.5-15.0.1.el4 and vixie-cron-4.1-47.EL4 I now get
the following selinux errors (running in targeted mode):

May 19 17:40:01 XXXXXXXX kernel: audit(1179596401.416:291): avc:  denied  {
transition } for  pid=3687 comm="crond" name="bash" dev=dm-1 ino=30113799
scontext=root:sysadm_r:initrc_t tcontext=system_u:system_r:unconfined_t

May 19 17:40:01 XXXXXXXX crond[3687]: (root) CMD (/usr/lib/sa/sa1 1 1)
May 19 17:40:01 XXXXXXXX crond[3687]: (root) error: Could not execve command
'/usr/lib/sa/sa1 1 1': Permission denied

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

How reproducible:
Not sure... running job from a root shell works fine, it's only failing via
cron.  I've also seen this bug mentioned on centos forums, but I couldn't find
any corresponding entry in RH bugzilla (I am running RHEL 4.5 not Centos).


Comment 1 Jason Corley 2007-05-22 17:06:04 UTC
This seems to fix:
    touch /.autorelabel
Would be nice to know what in the updated packages caused the relabel to be
necessary though (and why restorecon -R / didn't fix).

Comment 2 David Arnold 2007-06-24 14:44:04 UTC
I'm also experiencing this (or a very similar) problem.  Using RHEL4/x86_64, started experiencing a range 
of similar looking errors after an up2date -u.

How is this NOTABUG?
Is the fix in comment #1 the suggested procedure?

Comment 3 Daniel Walsh 2007-06-25 10:26:29 UTC
Have you tried the relabel?  The problem above is that crond was not running in
the correct context   So relabeling and restarting the cron daemon should fix
the problem.

Comment 4 David Arnold 2007-06-25 14:26:51 UTC
I have tried the 'restorecon -R /' and restarted crond.  That doesn't appear to
have fixed the problem.

I'll try the touch /.autorelabel + reboot tonight (this is a production fileserver).

Comment 5 David Arnold 2007-06-28 01:35:16 UTC
In fact, I tried a simple reboot (without touching the /.autorelabel) and things
seemed to recover.

Is there some mechanism by which admin staff should find out that an RHN update
requires a reboot, not only to eg. run a new kernel, but for the continued
healthy operation of the box?

Comment 6 Daniel Walsh 2007-06-28 11:10:23 UTC
No,  This really should not happen.  Why the restart did not fix the problem, I
don't know.  Perhaps the restart was not fully successful for some reason.

Comment 7 David Arnold 2007-06-28 13:16:12 UTC

Thanks for your help.

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