Bug 512576 - SEAlert popping up even when Quiet is selected
SEAlert popping up even when Quiet is selected
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: setroubleshoot (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks: F12Target 517000 558719 627668
  Show dependency treegraph
 
Reported: 2009-07-19 08:11 EDT by Edwin ten Brink
Modified: 2010-08-26 12:02 EDT (History)
6 users (show)

See Also:
Fixed In Version: 2.2.60-1.fc12
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 558719 (view as bug list)
Environment:
Last Closed: 2010-01-28 22:32:37 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 Edwin ten Brink 2009-07-19 08:11:08 EDT
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:
-
Comment 1 Daniel Walsh 2009-07-20 16:37:03 EDT
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
Comment 2 Edwin ten Brink 2009-07-20 17:25:15 EDT
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?
Comment 3 John Dennis 2009-07-20 18:19:15 EDT
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.
Comment 4 Daniel Walsh 2009-07-20 21:21:50 EDT
Edwin, So you are saying that the system does become quiet on reboot?
Comment 5 Edwin ten Brink 2009-07-21 02:24:09 EDT
(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)?
Comment 6 Daniel Walsh 2009-07-21 08:51:44 EDT
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?
Comment 7 Edwin ten Brink 2009-07-21 09:34:44 EDT
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.
Comment 8 Edwin ten Brink 2009-07-22 03:56:39 EDT
(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.
Comment 10 Juan P. Daza P. 2009-12-05 09:44:25 EST
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
Comment 11 Florian Fahr 2009-12-05 11:52:06 EST
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.
Comment 12 Daniel Walsh 2009-12-05 18:15:55 EST
Fixed in setroubleshoot-2.2.52-1
Comment 13 Florian Fahr 2009-12-06 04:18:18 EST
Nice!
Comment 14 Fedora Update System 2010-01-20 19:03:59 EST
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
Comment 15 Miroslav Vadkerti 2010-01-25 07:39:52 EST
VERIFIED as fixed in setroubleshoot-2.2.58-1.fc13, leaving open as updates-testing didn't update to this package for me
Comment 18 Fedora Update System 2010-01-28 22:31:31 EST
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.

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