Description of problem: Twice now I used up2date to update from RHEL4U1 to U2 and the up2date process seemed to finish without any errors. However, the following messages are sent to syslog many times a second: Oct 13 13:07:05 acs13 kernel: audit(1129223225.731:0): avc: granted { load_policy } for pid=31421 comm=load_policy scontext=root:sysadm_r:unconfined_t tcontext=system_u:object_r:security_t tclass=security Oct 13 13:09:54 acs13 kernel: audit(1129223394.651:0): security_compute_sid: invalid context root:sysadm_r:initrc_t for scontext=root:sysadm_r:unconfined_t tcontext=system_u:object_r:initrc_exec_t tclass=process Oct 13 13:09:54 acs13 kernel: audit(1129223394.651:0): avc: denied { read write } for pid=2191 comm=syslogd name=utmp dev=sda1 ino=491574 scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:var_run_t tclass=file Oct 13 13:09:54 acs13 kernel: audit(1129223394.651:0): avc: denied { read } for pid=2191 comm=syslogd name=utmp dev=sda1 ino=491574 scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:var_run_t tclass=file Oct 13 13:09:54 acs13 kernel: audit(1129223394.651:0): avc: denied { read write } for pid=350 comm=syslogd name=utmp dev=sda1 ino=491574 scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:var_run_t tclass=file Oct 13 13:09:54 acs13 kernel: audit(1129223394.651:0): avc: denied { read } for pid=350 comm=syslogd name=utmp dev=sda1 ino=491574 scontext=user_u:system_r:syslogd_t tcontext=user_u:object_r:var_run_t tclass=file How reproducible: Every time Steps to Reproduce: 1. up2date all packages from u1 to u2 Actual results: The system may become overwhelmed by the load of the log messages. And when the system is configured to send messages to a loghost the loghost may also become overwhelmed. Additional info: Not sure what component to file this bug under...
This looks like SE Linux messages. Adding Dan to bug report.
Wrong file context on utmp. restorecon /var/run/utmp
OK. So, something must have caused it to become incorrect, right? Seems like a real bug to me.
Did you boot with SELinux=0? Did you boot with a non SELinux kernel? Otherwise you will have to tell me how it got created with the wrong context. If an initscript created it, it should have the correct context. If another application deleted and recreated it, this is the context it would have.
Stock boot options for a stock kernel. I assume it must have had the correct context before the up2date because there were no error messages before that time.
Well I have no idea then. Watch it and report if it changes back. Dan
I'm not sure what you mean. The context issue seems to be fixed after a reboot. However, before then the system in some cases is DoS'd by the flood of log messages and if so configured a loghost may be nearly DoS'd too. However, up2date indicates none of this. My guess is that there is a bug in some %post or trigger script.
If a post install script removed and regenerated utmp this could happen. But without knowing which rpm package, it would be difficult to find. I also have not seen this bug reported by many others so I think it might be a strange occurrance. Of course I should be knocking on wood.
Can not reproduce.
Hey Daniel, sorry I never got back to this. I was able to reproduce it a few more times but could never pin it down to a particular package during the up2date. This hasn't happened recently. I'm tempted to blame up2date sucking ass. Thanks.