| Summary: | setroubleshoot detects alerts some times but sealert cannot display any error messages and command 'sealert -l' returns id not found. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Kenichi Takemura <ktakemur> | ||||
| Component: | setroubleshoot | Assignee: | Daniel Walsh <dwalsh> | ||||
| Status: | CLOSED NOTABUG | QA Contact: | Milos Malik <mmalik> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 6.1 | CC: | ebaak, ksrot, mgrepl, mmalik, pkovar | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | i386 | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | setroubleshoot-3.0.31-1.el6 | Doc Type: | Bug Fix | ||||
| Doc Text: |
Under certain circumstances, when the setroubleshoot utility detected alerts, the sealert utility was not able to display appropriate error messages and the "sealert -l" command returned the "id not found" error message. This bug has been fixed in this update so that sealert now works as expected.
|
Story Points: | --- | ||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2011-11-02 11:11:31 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Attachments: |
|
||||||
|
Description
Kenichi Takemura
2011-04-07 00:47:39 UTC
Since RHEL 6.1 External Beta has begun, and this bug remains unresolved, it has been rejected as it is not proposed as exception or blocker. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. Is this a translation problem? IE Can you try those commands with LANG=C and see if it works? Sometimes those commands could fail if the alert has been removed from the database. Alerts get removed if more then 50 different alerts get added. Or if a policy update fixes the problem. Hi I do not think this is an i18n issue. At least regarding 'sealert', as below it cannot find most recent incident id. $ sudo tail -20 /var/log/messages | grep setroubleshoot Apr 8 11:38:14 dhcp-1-167 setroubleshoot: SELinux は /bin/bash による "dac_override" アクセスを阻止しています . For complete SELinux messages. run sealert -l f9f042e3-4b82-4590-8738-e0df85a86995 Apr 8 11:38:14 dhcp-1-167 setroubleshoot: SELinux は /bin/bash による "dac_override" アクセスを阻止しています . For complete SELinux messages. run sealert -l f9f042e3-4b82-4590-8738-e0df85a86995 Apr 8 11:40:24 dhcp-1-167 setroubleshoot: [xml.ERROR] read_xml_file() libxml2.parserError: xmlParseFile() failed $ sudo LANG=C sealert -l f9f042e3-4b82-4590-8738-e0df85a86995 query_alerts error (1003): id (f9f042e3-4b82-4590-8738-e0df85a86995) not found $ sudo LANG=ja_JP.UTF8 sealert -l f9f042e3-4b82-4590-8738-e0df85a86995 query_alerts error (1003): id (f9f042e3-4b82-4590-8738-e0df85a86995) not found $ su パスワード: # LANG=C # sealert -l f9f042e3-4b82-4590-8738-e0df85a86995 query_alerts error (1003): id (f9f042e3-4b82-4590-8738-e0df85a86995) not found # LANG=en_US.UTF8 # sealert -l f9f042e3-4b82-4590-8738-e0df85a86995 query_alerts error (1003): id (f9f042e3-4b82-4590-8738-e0df85a86995) not found Please attach /var/lib/setroubleshoot/audit_listener_database.xml This xml database is what sealert is trying to read. Created attachment 491119 [details]
audit_listener_database.xml
Please find attached, thanks
Fixed in setroubleshoot-3.0.31-1.el6
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
New Contents:
Under certain circumstances, when the setroubleshoot utility detected alerts, the sealert utility was not able to display appropriate error messages and the "sealert -l" command returned the "id not found" error message. This bug has been fixed in this update so that sealert now works as expected.
If a common user runs "sealert -b" and deletes all alerts which are shown in the browser window then these alerts stop being visible for root user too. Which means that "sealert -l ..." will always produce following message: query_alerts error (1003): id (...) not found I would say that this behavior is a bug. Alerts written by setroubleshootd to /var/log/messages should be always visible for root. Is it possible that another user deleted some alerts via sealert browser window as described in comment#11 ? You can prevent common users from deleteing the alerts if you want by modifying setroubleshoot config. Hi Dan, how to prevent users from deleting alerts? By restriction of "client_users = *" in /etc/setroubleshoot/setroubleshoot.conf? Do you think that the default behavior (user can delete the alert) is fine? Yes that will work. Being able to delete alerts, is not changing the log files. The AVC still exists in the audit.log and perhaps referred to in the /var/log/messages. But if I had a multi-user machine, I would worry more about information leaks and might remove the setroubleshoot package and just leave the setroubleshoot-server package. The thing is that ordinary user can delete the alert but not to remove the setroubleshoot package. Once the alert is deleted, it is difficult to match the warning in /var/log/messages to the audit.log record. Admin user cannot use id , the only option that comes to my mind right now is to "decrypt" the timestamp in audit.log. How Dan said, the AVC msgs are available from audit.log for root user. If a root user doesn't want to allow a common user to remove alerts then there is an option. In that case this bug should be closed as NOT_A_BUG. Unless I am missing something. Per all comments I am closing this bug as NOTABUG. |