Re: aulast only displaying reboot pseudo-users
On Tuesday, June 17, 2014 10:31:25 AM Eric Paris wrote:
On Tue, 17 Jun 2014 16:09:32 +0200
Laurent Bigonville <bigon(a)debian.org> wrote:
> Le Tue, 17 Jun 2014 09:29:21 -0400,
>
> Steve Grubb <sgrubb(a)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