Bug 288881 - setroubleshoot failure when httpd is trying to access rpm_log_t
setroubleshoot failure when httpd is trying to access rpm_log_t
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: setroubleshoot (Show other bugs)
5.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: John Dennis
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-13 03:25 EDT by Jan-Frode Myklebust
Modified: 2008-05-21 10:25 EDT (History)
0 users

See Also:
Fixed In Version: RHSA-2008-0061
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-21 10:25:54 EDT
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 Jan-Frode Myklebust 2007-09-13 03:25:57 EDT
Description of problem:
I want the setroubleshooter to send me email on denials, 
so to test this I put a file of type "system_u:object_r:rpm_log_t"
into /var/www/html and tried to access it trough apache. This
gives me an AVC denial, and no mail. Setroubleshoot logs a traceback:

[root@via log]# 2007-09-12 11:49:54,887 [avc.ERROR] Plugin Exception
plugins.httpd_bad_labels
Traceback (most recent call last):
  File "/usr/lib/python2.4/site-packages/setroubleshoot/analyze.py", line 260,
in analyze_avc
    report_receiver.report_problem(report)
  File "/usr/lib/python2.4/site-packages/setroubleshoot/server.py", line 145, in
report_problem
    self.database.set_filter(self, siginfo.sig, addr, FILTER_ALWAYS)
  File "/usr/lib/python2.4/site-packages/setroubleshoot/analyze.py", line 468,
in set_filter
    siginfo = self.lookup_signature(sig)
  File "/usr/lib/python2.4/site-packages/setroubleshoot/analyze.py", line 388,
in lookup_signature
    matches = self.sigs.match_signatures(sig)
  File "/usr/lib/python2.4/site-packages/setroubleshoot/signature.py", line
1265, in match_signatures
    if pat.__dict__[name] == sig.__dict__[name]:
KeyError: 'analysis_id'
2007-09-12 11:49:55,034 [avc.ERROR] Plugin Exception plugins.disable_trans
Traceback (most recent call last):
  File "/usr/lib/python2.4/site-packages/setroubleshoot/analyze.py", line 260,
in analyze_avc
    report_receiver.report_problem(report)
  File "/usr/lib/python2.4/site-packages/setroubleshoot/server.py", line 145, in
report_problem
    self.database.set_filter(self, siginfo.sig, addr, FILTER_ALWAYS)
  File "/usr/lib/python2.4/site-packages/setroubleshoot/analyze.py", line 468,
in set_filter
    siginfo = self.lookup_signature(sig)
  File "/usr/lib/python2.4/site-packages/setroubleshoot/analyze.py", line 388,
in lookup_signature
    matches = self.sigs.match_signatures(sig)
  File "/usr/lib/python2.4/site-packages/setroubleshoot/signature.py", line
1265, in match_signatures
    if pat.__dict__[name] == sig.__dict__[name]:
KeyError: 'analysis_id'
2007-09-12 11:49:55,170 [avc.ERROR] Plugin Exception plugins.catchall_file
Traceback (most recent call last):
  File "/usr/lib/python2.4/site-packages/setroubleshoot/analyze.py", line 260,
in analyze_avc
    report_receiver.report_problem(report)
  File "/usr/lib/python2.4/site-packages/setroubleshoot/server.py", line 145, in
report_problem
    self.database.set_filter(self, siginfo.sig, addr, FILTER_ALWAYS)
  File "/usr/lib/python2.4/site-packages/setroubleshoot/analyze.py", line 468,
in set_filter
    siginfo = self.lookup_signature(sig)
  File "/usr/lib/python2.4/site-packages/setroubleshoot/analyze.py", line 388,
in lookup_signature
    matches = self.sigs.match_signatures(sig)
  File "/usr/lib/python2.4/site-packages/setroubleshoot/signature.py", line
1265, in match_signatures
    if pat.__dict__[name] == sig.__dict__[name]:
KeyError: 'analysis_id'



Version-Release number of selected component (if applicable):

setroubleshoot-1.8.11-4.el5

How reproducible:

Very.

Steps to Reproduce:

assuming both httpd and setroubleshoot is running..
  
1. cp -a /var/log/rpmpkgs /var/www/html/test.html
2. chmod a+r /var/www/html/test.html
3. tail -f /var/log/setroubleshoot/setroubleshootd.log
4. try to access http://localhost/test.html
Actual results:


Expected results:


Additional info:
Comment 1 John Dennis 2007-09-15 14:16:34 EDT
I think you might have a corrupted alert database. To test this theory lets move
the database to the side so a new one is freshly created, and then re-run your
test. To do this you'll need to be root.

% cd /var/lib/setroubleshoot
% mv audit_listener_database.xml audit_listener_database.xml.bak
% service setroubleshoot restart

Now run you test again. Did it succeed? If yes, then we found the problem and I
would like to look at the database to see if I can tell how it got corrupted. Do
not attach the database to this bug report if there is security sensitive
information in it, if that's the case we'll figure out another way to diagnose
the corruption. Also, please /var/log/setroubleshootd/setroubleshootd.log to see
if there were earlier error messages which might account for the corruption.

If the test still fails then I'll need to see the exact audit log messages. To
do that open the file /var/log/audit/audit.log. The audit messages your test
generaged should be near the bottom. Please note there will likely be several
lines comprising the audit event, they will all share the same audit event ID
(e.g. audit(nnn.nnn.:nnn), I'll need each of those lines.

HTH,

John


Comment 2 Jan-Frode Myklebust 2007-09-15 14:31:31 EDT
No, that didn't change anything. Here's the auditd lines generated:

type=AVC msg=audit(1189881018.389:116302): avc:  denied  { getattr } for 
pid=2858 comm="httpd" name="z.html" dev=dm-4 ino=540680
scontext=root:system_r:httpd_t:s0 tcontext=system_u:object_r:rpm_log_t:s0
tclass=file
type=SYSCALL msg=audit(1189881018.389:116302): arch=40000003 syscall=195
success=no exit=-13 a0=85f1c68 a1=bfb05b9c a2=385ff4 a3=8170 items=0 ppid=2851
pid=2858 auid=0 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48
tty=(none) comm="httpd" exe="/usr/sbin/httpd" subj=root:system_r:httpd_t:s0
key=(null)
type=AVC_PATH msg=audit(1189881018.389:116302):  path="/var/www/html/z.html"
type=AVC msg=audit(1189881018.394:116303): avc:  denied  { getattr } for 
pid=2858 comm="httpd" name="z.html" dev=dm-4 ino=540680
scontext=root:system_r:httpd_t:s0 tcontext=system_u:object_r:rpm_log_t:s0
tclass=file
type=SYSCALL msg=audit(1189881018.394:116303): arch=40000003 syscall=196
success=no exit=-13 a0=85f1cf0 a1=bfb05b9c a2=385ff4 a3=2008171 items=0
ppid=2851 pid=2858 auid=0 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48
fsgid=48 tty=(none) comm="httpd" exe="/usr/sbin/httpd"
subj=root:system_r:httpd_t:s0 key=(null)
type=AVC_PATH msg=audit(1189881018.394:116303):  path="/var/www/html/z.html"
Comment 3 Jan-Frode Myklebust 2007-09-15 14:41:14 EDT
Hmm, just noticed that I didn't get this with the default
/etc/setroubleshoot/setroubleshoot.cfg , but when I define a single "recepients"
email address the failures start.
Comment 4 John Dennis 2007-09-15 15:02:27 EDT
re comment #3, thanks, that helps narrow it down. Were there any errors in
setroubleshootd.log prior to the traceback complaining about the missing
"analysis_id"?

In the mean time I'll look at the code to see if there is an ordering problem
when an email is generated.

Thank you for your help in diagnosing this.
Comment 5 Jan-Frode Myklebust 2007-09-15 15:10:00 EDT
No, this is the only entry I found in the log. And I just tested this on another
system where I hadn't been messing with the setroubleshootd.cfg before.. 
Comment 6 RHEL Product and Program Management 2007-12-18 17:15:37 EST
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 8 John Dennis 2008-01-09 14:02:13 EST
This should be resolved in the setroubleshoot 2.0 series. The way email
recipients  is specified is now different (done through the GUI or by editing
/var/lib/setroubleshoot/email_alert_recipients if the GUI is not present).

Email notifications have been tested in the 2.0 series and this issue does not
present.
Comment 11 errata-xmlrpc 2008-05-21 10:25:54 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2008-0061.html

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