Bug 174865 - DAEMON_CONFIG audit record isn't right
DAEMON_CONFIG audit record isn't right
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: audit (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Steve Grubb
Brian Brock
Depends On:
Blocks: 175213 RHEL4U4Audit 181409
  Show dependency treegraph
Reported: 2005-12-02 18:06 EST by Linda Knippers
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version: RHBA-2006-0379
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-08-10 17:16:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
prototype fix (2.12 KB, patch)
2005-12-02 18:06 EST, Linda Knippers
no flags Details | Diff
reworked patch isolating the time stamp issue (1.69 KB, patch)
2005-12-07 14:36 EST, Steve Grubb
no flags Details | Diff
patch isolating the switched parameters (565 bytes, patch)
2005-12-07 14:41 EST, Steve Grubb
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2006:0379 normal SHIPPED_LIVE audit enhancement update 2006-08-09 00:00:00 EDT

  None (edit)
Description Linda Knippers 2005-12-02 18:06:17 EST
Description of problem:
There are actually two problems with the DAEMON_CONFIG record but they're
in the same code so I'm just filing one bug.  The main problem is that
there is no timestamp on this record.  This problem exists at least 
up until 1.0.12.  The minor problem is that ausearch can't find the
record.  This is fixed in 1.0.12 (perhaps earlier) but is broken in
1.0.4, so we need a fix to that version.

Patches are included.  The timestamp fix is awkward (replicates most of
send_audit_event, even some that's not necessary because it won't ever
be the first message, and there's a malloc failure case that's not really
handled) but I'm providing it as a starting point that you will probably
want to improve on.  The ausearch fix to auditd is the same as is in

Version-Release number of selected component (if applicable):
RHEL4U2 with audit 1.0.4+auditctl fix

How reproducible:
Reproduces every time

Steps to Reproduce:
1. start the auditd
2. run /etc/init.d/auditd reload
3. look in the audit.log and see that the record is there but no timestamp
4. run ausearch -m DAEMON_CONFIG and ausearch will find no match
Actual results:
type=DAEMON_CONFIG msg=config changed, auid=2063 pid=23485 res=success

Expected results:
type=DAEMON_CONFIG msg=audit(1133562160.429:649) config changed, auid=2063,
pid=31214, res=success

Additional info:
Comment 1 Linda Knippers 2005-12-02 18:06:17 EST
Created attachment 121788 [details]
prototype fix
Comment 2 Linda Knippers 2005-12-02 18:09:53 EST
I forgot to mention that the example in the Actual results is from 1.0.12.
The 1.0.4 version has the auid and pid field reversed (causes ausearch to
not find the record) and no res= field, but Steve will recognize that.
Comment 3 Steve Grubb 2005-12-07 14:36:23 EST
Created attachment 121992 [details]
reworked patch isolating the time stamp issue

This is the proposed patch to fix the time stamp issue.
Comment 4 Steve Grubb 2005-12-07 14:41:11 EST
Created attachment 121995 [details]
patch isolating the switched parameters
Comment 8 Bob Johnson 2006-04-11 13:11:54 EDT
This issue is on Red Hat Engineering's list of planned work items 
for the upcoming Red Hat Enterprise Linux 4.4 release.  Engineering 
resources have been assigned and barring unforeseen circumstances, Red 
Hat intends to include this item in the 4.4 release.
Comment 12 Red Hat Bugzilla 2006-08-10 17:16:33 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.


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