Bug 170685 - up2date from u1 to u2 causes system to freak out
up2date from u1 to u2 causes system to freak out
Status: CLOSED WORKSFORME
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: audit (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Steve Grubb
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-13 15:04 EDT by jmccann
Modified: 2015-01-14 18:19 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 19:06:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description jmccann 2005-10-13 15:04:37 EDT
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 17:15:42 EDT
This looks like SE Linux messages. Adding Dan to bug report.
Comment 2 Daniel Walsh 2005-10-15 13:04:22 EDT
Wrong file context on utmp.

restorecon /var/run/utmp
Comment 3 jmccann 2005-10-17 12:04:35 EDT
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 15:03:07 EDT
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 15:07:09 EDT
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 15:32:02 EDT
Well I have no idea then.  Watch it and report if it changes back.

Dan
Comment 7 jmccann 2005-10-17 15:37:52 EDT
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 16:19:37 EDT
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-21 19:06:10 EST
Can not reproduce.
Comment 10 jmccann 2006-02-21 19:10:23 EST
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.

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