From: Steve Grubb <sgrubb@redhat.com>
To: Eric Paris <eparis@redhat.com>
Cc: linux-audit@redhat.com
Subject: Re: aulast only displaying reboot pseudo-users
Date: Tue, 17 Jun 2014 10:56:24 -0400 [thread overview]
Message-ID: <7885595.OZveFJzaAO@x2> (raw)
In-Reply-To: <20140617103125.1871abbf@flatline.rdu.redhat.com>
On Tuesday, June 17, 2014 10:31:25 AM Eric Paris wrote:
> On Tue, 17 Jun 2014 16:09:32 +0200
>
> Laurent Bigonville <bigon@debian.org> wrote:
> > Le Tue, 17 Jun 2014 09:29:21 -0400,
> >
> > Steve Grubb <sgrubb@redhat.com> a écrit :
> > > On Monday, June 16, 2014 05:20:10 PM Eric Paris wrote:
> > [...]
> >
> > > > I'd call this a pretty clear userspace bug where it just
> > > > completely drops records, even if it can't parse them...
> > >
> > > That theory can be tested by using:
> > >
> > > ausearch --start this-week --debug > /dev/null
> > >
> > > Anything that gets tossed out will be reported to stderr.
> >
> > I'm getting indeed quite a lot of skipped event:
> >
> > Malformed event skipped, rc=7. type=LOGIN
> > msg=audit(1402934401.462:1626): pid=1719 uid=0 old-auid=4294967295
> > new-auid=0 old-ses=4294967295 new-ses=121 res=1
>
> This feel like 2 clear bugs.
>
> 1) The kernel records for LOGIN are 'malformed' in 3.14.
Was the patch sent to stable? If not, could it be?
> 2) Userspace silently throws records which are 'malformed' away, instead
> of just printing them...
>
> ausearch -m LOGIN should be able to display these things...
The problem is that all of the utilities are expecting fields with certain
names in a certain order. Moving them around or changing them breaks things.
When we add work-arounds, it causes the utilities to run slower because it
tries one method and then another. When you run test cases that parse 100 Gb
of logs, you'll see the effects of the work-arounds because the search takes
minutes rather than seconds. The utilities are tuned for the massive logs use
case.
The particular code in question, ausearch-parse.c is used by both aureport and
ausearch. It does not have a concept of completing search criteria and just
dumping the record out. There might be something that can be done here, but
lots a changes risks breaking things in subtle ways.
-Steve
next prev parent reply other threads:[~2014-06-17 14:56 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-04 22:04 aulast only displaying reboot pseudo-users Laurent Bigonville
2014-06-04 22:23 ` Steve Grubb
2014-06-04 22:42 ` Laurent Bigonville
2014-06-04 23:04 ` Steve Grubb
2014-06-05 17:34 ` Laurent Bigonville
2014-06-14 11:53 ` Laurent Bigonville
2014-06-16 21:20 ` Eric Paris
2014-06-16 21:24 ` Eric Paris
2014-06-16 21:28 ` Eric Paris
2014-06-17 13:29 ` Steve Grubb
2014-06-17 14:09 ` Laurent Bigonville
2014-06-17 14:31 ` Eric Paris
2014-06-17 14:55 ` Richard Guy Briggs
2014-06-17 15:04 ` Steve Grubb
2014-06-17 14:56 ` Steve Grubb [this message]
2014-06-17 15:15 ` Richard Guy Briggs
2014-06-17 15:26 ` Eric Paris
2014-06-17 16:30 ` Steve Grubb
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=7885595.OZveFJzaAO@x2 \
--to=sgrubb@redhat.com \
--cc=eparis@redhat.com \
--cc=linux-audit@redhat.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