Bug 240665 - selinux errors after updating sysstat and vixie-cron
selinux errors after updating sysstat and vixie-cron
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: selinux-policy (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Depends On:
  Show dependency treegraph
Reported: 2007-05-19 13:51 EDT by Jason Corley
Modified: 2007-11-16 20:14 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-06-21 09:28:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jason Corley 2007-05-19 13:51:54 EDT
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 13:06:04 EDT
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 10:44:04 EDT
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 06:26:29 EDT
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 10:26:51 EDT
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-27 21:35:16 EDT
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 07:10:23 EDT
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 09:16:12 EDT

Thanks for your help.

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