Description of problem: Selecting Quiet for an AVC denial in SETroubleshoot does not prevent an SEAlert from popping up. Version-Release number of selected component (if applicable): $ rpm -q setroubleshoot setroubleshoot-2.1.14-1.fc11.i586 How reproducible: Always. Steps to Reproduce: 1. Make sure you have a reproducible AVC denial. 2. Mark it as Quiet in SETroubleshoot. 3. Reproduce the same AVC denial Actual results: SEAlert popping up for the Quiet AVC denial. Expected results: No SEAlert for this AVC denial. Additional info: -
Could you show the two AVC's so we can determine if SELinux thought they were the same. If a componant like target file or source file changed it could cause setroubleshoot to see them as different AVC;s
It concerns the AVC denial I reported under bug 510950. It has a count of 60 in the mean time (Thunderbird produces the same AVC denial times 4 at each startup). SELinux does explicitly list them as counts of the same AVC denial, it does not create a new one (so the AVC's must be identical, I cannot reproduce more than one AVC text). I have been trying to narrow down this problem and found out that the set or reset of Quiet requires a reboot for changes to take effect. This is not what I would intuitively expect. Was that by design?
quiet is supposed to immediately silence the alerts, however a lot of the code was recently rewritten to support a different GUI, I suspect the silencing of the alerts was lost or broken during the rewrite so my guess is this is a new bug in the GUI.
Edwin, So you are saying that the system does become quiet on reboot?
(In reply to comment #4) > Edwin, So you are saying that the system does become quiet on reboot? Yes, that's exactly what happens. The same goes BTW for the opposite (unselecting Quiet). In the same session, changing the selection does not appear to do anything, but the setting prior to a reboot will take effect after booting. It appears that the setting is saved but the alert logic is not updated after a change but only after rebooting. (In reply to comment #3) Shouldn't this bug then be marked as a regression (in the Keyword)?
Well, I think what is happening, is it is only getting written when setroubleshoot the server exits. The redesign is to not run setroubleshoot and sealert all of the time. So if you change the flag and then exit sealert, the setroubleshoot daemon should exit after about 10 seconds as long as no new AVC's come in. You can verify this by looking foor setroubleshootd ps -eZ | grep setroubleshoot Now generate the AVC's again, and it should follow the current selection similarly to a reboot. If not I have no idea what is going on. Thomas, we reworked this in Rawhide correct?
Ok, I have now confused setroubleshoot completely... :-/ In all this rebooting, changing the flag back and forth and your suggestion, I seemed not able to reproduce the behaviour any more for the past half hour, even the AVC denial seemed gone. I'm not sure what caused it, but now regardless of the status of the checkmark, setroubleshoot does no longer present an alert, does not increment the count, yet when I query /var/log/messages, I still see the AVC denials coming... In the mean time, the count in setroubleshoot is 88, but in /var/log/messages it is 116 at the same moment. The difference is the set of attempts to reproduce the alert in the past half hour (seven attempts which each cause four avc's, so it all adds up nicely). This is getting weirder every time. Now I don't have any clue as how to try to track down this problem.
(In reply to comment #6) > Well, I think what is happening, is it is only getting written when > setroubleshoot the server exits. (...) > So if you change the flag and then exit sealert, the setroubleshoot > daemon should exit after about 10 seconds as long as no new > AVC's come in. (...) > Now generate the AVC's again, and it should follow the current selection > similarly to a reboot. > > If not I have no idea what is going on. Somehow things normalized this morning and I was able to test your suggestion. Unfortunately, this suggestion did not solve the problem: the alert popped up again.
Thank you for taking the time to report this bug. Updates to this package have been released since it was first reported. If you have time to update the package and re-test, please do so and report the results here. You can obtain the updated package by typing 'yum update setroubleshoot' or using the graphical updater, Software Update. --- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Still happens (setroubleshoot-2.2.46-1.fc12.i686). I keep getting lots of these when using Chromium. Interesting fact is that even setroubleshoot knows that this exact same "violation" has occurred before. Doesn't keep it from popping up constantly, even though I checked the "Ignore all forther instances of this bug" checkbox.
Fixed in setroubleshoot-2.2.52-1
Nice!
setroubleshoot-2.2.58-1.fc12 has been pushed to the Fedora 12 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'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-0815
VERIFIED as fixed in setroubleshoot-2.2.58-1.fc13, leaving open as updates-testing didn't update to this package for me
setroubleshoot-2.2.60-1.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.