From: Steve Grubb <sgrubb@redhat.com>
To: John Dennis <jdennis@redhat.com>
Cc: William Kelly <wkelly@rackspace.com>,
linux-audit@redhat.com, Bret Piatt <bret.piatt@rackspace.com>
Subject: Re: get_field_str() and interpret_field() bug with multi-word fields
Date: Tue, 12 Aug 2008 17:53:09 -0400 [thread overview]
Message-ID: <200808121753.10501.sgrubb@redhat.com> (raw)
In-Reply-To: <48A20330.7090206@redhat.com>
On Tuesday 12 August 2008 17:40:00 John Dennis wrote:
> Bad example, proc works because it's (mostly) well defined.
What does the 25th field in /proc/1/stat mean? You can't tell without looking
at the kernel source code.
> > The point is that all of /proc is written without implicit parsing rules.
> > That's the way it is when dealing with kernel and its user space
> > utilities. There is no field in the kernel that is unhandled by the audit
> > system and without knowing specifically what's in it.
>
> I'm sorry Steve, but this simply doesn't work. How the heck am I
> supposed to correctly parse an audit log file from 5 years ago if either
> I don't know the kernel version that produced it
ausearch --start today -m DAEMON_START
----
time->Tue Aug 12 08:03:52 2008
node=127.0.0.1 type=DAEMON_START msg=audit(1218542632.238:4562): auditd start,
ver=1.7.4 format=raw kernel=2.6.26-0.17.rc3.sg3.fc9.x86_64 auid=4294967295
pid=2139 res=success
> or have available the matching user space tools from that era? This is going
> to be an absolute nightmare for IPA and other compliance tools.
With backwards compatibility you don't have to worry about having tools of
that era.
-Steve
next prev parent reply other threads:[~2008-08-12 21:53 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-12 17:49 get_field_str() and interpret_field() bug with multi-word fields Jonathan Kelly
2008-08-12 18:05 ` LC Bruzenak
2008-08-12 18:52 ` John Dennis
2008-08-12 19:02 ` LC Bruzenak
2008-08-12 18:16 ` John Dennis
2008-08-12 21:13 ` Steve Grubb
2008-08-12 22:10 ` Matthew Booth
2008-08-12 23:01 ` Eric Paris
2008-08-12 19:16 ` Steve Grubb
2008-08-12 19:58 ` John Dennis
2008-08-12 20:11 ` Eric Paris
2008-08-12 20:32 ` Steve Grubb
2008-08-12 21:09 ` John Dennis
2008-08-12 21:24 ` Steve Grubb
2008-08-12 22:37 ` John Dennis
2008-08-13 0:33 ` Klaus Heinrich Kiwi
2008-08-13 15:09 ` Eric Paris
2008-08-13 16:25 ` Klaus Heinrich Kiwi
2008-08-13 17:02 ` Steve Grubb
2008-08-13 17:30 ` LC Bruzenak
2008-08-13 18:49 ` Linda Knippers
2008-08-13 19:58 ` John Dennis
2008-08-14 18:25 ` Stephen Smalley
2008-08-15 13:58 ` Matteo Michelini
2008-08-15 14:10 ` Steve Grubb
2008-08-15 15:27 ` Matteo Michelini
2008-08-15 14:15 ` Stephen Smalley
2008-08-13 16:29 ` John Dennis
2008-08-13 22:35 ` Casey Schaufler
2008-08-12 20:57 ` John Dennis
2008-08-12 21:18 ` Steve Grubb
2008-08-12 21:40 ` John Dennis
2008-08-12 21:53 ` Steve Grubb [this message]
2008-08-12 22:11 ` John Dennis
2008-08-12 22:46 ` Steve Grubb
2008-08-12 22:59 ` Eric Paris
-- strict thread matches above, loose matches on Subject: below --
2008-08-13 16:57 Jonathan Kelly
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200808121753.10501.sgrubb@redhat.com \
--to=sgrubb@redhat.com \
--cc=bret.piatt@rackspace.com \
--cc=jdennis@redhat.com \
--cc=linux-audit@redhat.com \
--cc=wkelly@rackspace.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox