11:11 a.m.
In the functions auparse_timestamp_compare() and events_are_equal() the
host field is not checked, is that by design or omission? Should two
different events from two different hosts be comparable?
On a side note, the use of the term timestamp in symbol names like
auparse_timestamp_compare() seems misleading because the item in
question is not really a timestamp, rather its an event identifier which
contains some time information. Are we too far down the road to call
this object an 'event_id'?
--
John Dennis <jdennis(a)redhat.com>
11:23 a.m.
On Wednesday 05 September 2007 12:11:46 John Dennis wrote:
In the functions auparse_timestamp_compare() and events_are_equal()
the
host field is not checked, is that by design or omission?
When the API was designed, the node was not part of the records. Its only
since audit-1.6 that it was. I had not considered adding a node check since
the function was originally there to add comparing two datatypes that are not
straight forward.
Should two different events from two different hosts be comparable?
In a consolidated log, they are not equal. I suppose that should be fixed in
the next release.
Are we too far down the road to call this object an
'event_id'?
Yes.
-Steve
11:37 a.m.
On Wed, 2007-09-05 at 12:23 -0400, Steve Grubb wrote:
On Wednesday 05 September 2007 12:11:46 John Dennis wrote:
> Should two different events from two different hosts be comparable?
In a consolidated log, they are not equal. I suppose that should be fixed in
the next release.
Right, but the way the cmp operator works is if it's not equal it's
either less than or greater than, neither of which is meaningful as a
result if they are not from the same host, right?
Currently the API does not support a way to return an error code for the
compare function, but it's an error to compare two records who do not
share the same host value. At the moment all I can think of is that
auparse_timestamp_compare() will have to be deprecated and replaced with
a different function, unless you have a better idea. Suggestions?
--
John Dennis <jdennis(a)redhat.com>
12:17 p.m.
On Wednesday 05 September 2007 12:37:08 John Dennis wrote:
On Wed, 2007-09-05 at 12:23 -0400, Steve Grubb wrote:
> On Wednesday 05 September 2007 12:11:46 John Dennis wrote:
> > Should two different events from two different hosts be comparable?
>
> In a consolidated log, they are not equal. I suppose that should be fixed
> in the next release.
Right, but the way the cmp operator works is if it's not equal it's
either less than or greater than,
Yeah, and I want to leave it that way. Its intent is to provide a way to
compare a data type that is not straight forward.
neither of which is meaningful as a result if they are not from the
same
host, right?
What you seek is a yes/no answer. Are they from the same host? Cause based on
that answer, you may or may not want to compare timestamps.
At the moment all I can think of is that auparse_timestamp_compare()
will
have to be deprecated and replaced with a different function, unless you
have a better idea. Suggestions?
It could be incumbent on the programmer to know what's being compared. :)
I think this is a common database programming issue. (auparse is modelled
after database functions.) Suppose you have a POS database. You have sales
information from many stores. If you want to total the sales from a
particular store, you have to select that store within a time range. If you
wanted all sales for a day, you just check timestamps.
IOW, I think the programmer should know what they are trying to do and take
nodes into account. We can easily write a function that takes 2 events and
decides if they are from the same node. That would give you the yes/no
answer.
-Steve
6233
days inactive
6233
days old
linux-audit@lists.linux-audit.osci.io
3 comments
2 participants
participants (2)
-
John Dennis -
Steve Grubb