Bug 170685

Summary: up2date from u1 to u2 causes system to freak out
Product: Red Hat Enterprise Linux 4 Reporter: jmccann
Component: auditAssignee: Steve Grubb <sgrubb>
Status: CLOSED WORKSFORME QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.0CC: cschalle, dwalsh
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-02-22 00:06:10 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description jmccann 2005-10-13 19:04:37 UTC
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...

Comment 1 Steve Grubb 2005-10-14 21:15:42 UTC
This looks like SE Linux messages. Adding Dan to bug report.

Comment 2 Daniel Walsh 2005-10-15 17:04:22 UTC
Wrong file context on utmp.

restorecon /var/run/utmp


Comment 3 jmccann 2005-10-17 16:04:35 UTC
OK.  So, something must have caused it to become incorrect, right?  Seems like a
real bug to me.

Comment 4 Daniel Walsh 2005-10-17 19:03:07 UTC
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.

Comment 5 jmccann 2005-10-17 19:07:09 UTC
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.

Comment 6 Daniel Walsh 2005-10-17 19:32:02 UTC
Well I have no idea then.  Watch it and report if it changes back.

Dan

Comment 7 jmccann 2005-10-17 19:37:52 UTC
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.

Comment 8 Daniel Walsh 2005-10-17 20:19:37 UTC
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.

Comment 9 Daniel Walsh 2006-02-22 00:06:10 UTC
Can not reproduce.

Comment 10 jmccann 2006-02-22 00:10:23 UTC
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.