Description of problem: During development there are a couple of applications I use which do not yet have suitable policy, and thus inheriting the confined domain of the app which launches them. When these apps run it is 100% guarrenteed that they will generate a number of AVC warnings. One of these apps runs once an hour. The result is that once an hour 'setroubleshoot' pops up its little warning & logs a large bunch of AVCs I can do nothing about, nor do I care about them. There are other AVCs that I *do* want to track, but the repeated reporting of AVCs I don't care about makes it impractical to use setroubleshoot at all. Deleting the AVCs doesn't help, because they'll just be re-reported in the future. What setroubleshoot needs in order to be useful, is a way to permantly block individual AVCs so if the same one occurs in the future it will not be re-reported. Version-Release number of selected component (if applicable): setroubleshoot-1.10.7-1.fc8 How reproducible: N/A Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
This is precisely the purpose of the "Filter" checkbox in the browser. Check the filter checkbox for the alert and you won't be alerted for that AVC. BTW, I'm aware the name column name "Filter" is probably a poor choice. The name came into existence because the "alert is filtered", but most user's won't make that connection. FWIW, I've updated the column name in the latest version to be "Quiet", hopefully that will be more intuitive.
This merely removes the status bar icon alert AFAICT - the 'filtered' AVCs are still shown in the big browser list of AVCs. Its desirable to have them hidden there too since that listing of AVCs can get enourmous otherwise.
As a workaround you can mark the alert as deleted and then under the View memu select "Hide Deleted". This works much like a IMAP email client. Would you be happy with a view option which hid quiet alerts? That way you wouldn't see any alerts which were marked as "quiet", this would be independent of the delete status.
Oh, BTW the number of alerts should never be huge. We try to coalesce similar alerts into a single alert. This was somewhat broken in some releases, if you're getting a huge number I'd like to know what they are. Also, recent vintage releases will automatically prune the number of active alerts to keep things managible, I think the default is 30, it's a configuration parameter in /etc/setroubleshoot/setroubleshoot.cfg.
I'm getting a huge number because of a couple of particular applications I'm experimenting with which have some serious flaws, hence really do generate lots of unique / different AVCs. A view option to hide any 'quiet' alerts would work for me.
O.K. done. I've implemented "hide quiet". Should appear in next build, probably setroubleshoot-2.0.1-1
setroubleshoot-2.0.2-1.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update setroubleshoot'
setroubleshoot-plugins-2.0.4-3.fc8,setroubleshoot-2.0.5-2.fc8 has been submitted as an update for Fedora 8
setroubleshoot-plugins-2.0.4-3.fc8, setroubleshoot-2.0.5-2.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.