Red Hat Bugzilla – Bug 240665
selinux errors after updating sysstat and vixie-cron
Last modified: 2007-11-16 20:14:55 EST
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): /var/log/messages: 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 tclass=process /var/log/cron: 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): sysstat-5.0.5-15.0.1.el4 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). http://www.centos.org/modules/newbb/viewtopic.php?topic_id=4653
This seems to fix: touch /.autorelabel reboot Would be nice to know what in the updated packages caused the relabel to be necessary though (and why restorecon -R / didn't fix).
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?
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.
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).
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?
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.
Ok. Thanks for your help.