Bug 455977

Description of problem:
Yesterday I updated to the latest targeted policy, which caused the gam_server's
context to be invalidated. As a result, I got 5224 events reporting the various
denials, until I rebooted my computer. The browser was popping up a balloon for
each and every event, even after I had opened the browser. This doesn't seem
like it's the right strategy for handling events.

Had setrouble acted more sanely, I would have been able to diagnose what was
wrong without having to resort to rebooting the computer. My other attempt,
stopping setroubleshoot's daemon, had the effect of disconnecting the browser
and making it unable to view anything at all.

Version-Release number of selected component (if applicable):
setroubleshoot-2.0.8-2.fc9.noarch

How reproducible:
That kind of mass-denial doesn't occur often, but should be pretty easy to
induce reliably.

Steps to Reproduce:
1. Do something that will generate denials at a very high rate (this should be
easy to tune with a custom executable)
2. Watch the madness
3.
  
Actual results:
The browser has a lot of trouble keeping up, balloons are popping up repeatedly,
even after I've opened the browser, etc.

Expected results:
setroubleshoot should calmly let me know something is wrong. Perhaps it could
start with with the current behavior, but after the denial count starts to get
large (where "large" might be 10 -- we're talking balloon popups here, after
all) it switches to "something appears to be very wrong here"-like behavior (a
single popup in red saying something to that effect, for example).

Also, if I have the browser open, that is giving me feedback that the counts are
increasing, so I don't really need the balloons anymore. The repeating balloons
are annoying even for a low number of denials.

Furthermore, I should still be able to look at the denials that have been
processed already. After a while, the GUI stopped updating, and I couldn't tell
what was wrong.

Beyond that, I have no specific suggestions. High denial counts shouldn't
happen, but when they do, it's important that the user can get to the bottom of
what's wrong quickly.

Additional info:
Here's a summary of /var/log/messages:
Jul 18 20:27:48 elminster yum: Updated: selinux-policy-3.3.1-78.fc9.noarch
Jul 18 20:28:23 elminster kernel: security:  invalidating context
system_u:system_r:gamin_t:s0-s0:c0.c1023
Jul 18 20:28:23 elminster kernel: security:  invalidating context
unconfined_u:system_r:gamin_t:s0-s0:c0.c1023
Jul 18 20:28:23 elminster kernel: security:  invalidating context
system_u:system_r:gamin_t:s0
Jul 18 20:28:23 elminster kernel: SELinux: policy loaded with handle_unknown=allow
Jul 18 20:28:23 elminster dbus: avc:  received policyload notice (seqno=2)
Jul 18 20:28:28 elminster yum: Updated: selinux-policy-targeted-3.3.1-78.fc9.noarch
Jul 18 20:28:30 elminster audispd: queue is full - dropping event
[repeat 192 times]
Jul 18 20:28:31[-37] elminster setroubleshoot: SELinux is preventing gam_server
(unlabeled_t) "getattr" to inotify (inotifyfs_t). For complete SELinux messages.
run sealert -l ccad94d1-5cdb-4661-8c07-fe81274e71c1
Jul 18 20:28:31[-37] elminster setroubleshoot: SELinux is preventing gam_server
(unlabeled_t) "read" to inotify (inotifyfs_t). For complete SELinux messages.
run sealert -l cad8f871-05ce-42c9-b43f-5cf356f7ce68
[repeat 47 times]
[repeat audispd/setroubleshoot messages 7330 times through 20:33:17]
<shutdown/reboot>