auparse with AUSOURCE_DESCRIPTOR

Satish Chandra Kilaru iam.kilaru at gmail.com
Thu Jul 30 16:34:26 UTC 2015


Thank you. I went through the example code.
I do not see how FEED is better than using descriptor. Probably I am
missing something.

--Satish

On Thu, Jul 30, 2015 at 12:12 PM, Steve Grubb <sgrubb at redhat.com> wrote:

> On Thursday, July 30, 2015 10:16:53 AM Satish Chandra Kilaru wrote:
> > Never mind... I found out why it was not working...
>
> The auparse API expects string formatted events. The binary interface
> exists
> in case you completely understand how the audit events are formatted and
> prefer to take events as they come out.
>
> For anyone not completely familiar with the data structures, its better to
> just use strings. In thsi way, you can extract portions of the log using
> ausearch --raw > test.log  and then feed that to your program for
> debugging.
>
>
> > 1. auparse_next_event() does not call callback function. I have to call
> > that function when auparse_next_event() returns.
>
> The next event function is normally used when you are iterating through a
> file.
> If you are taking real-time events, its best to use the feed API and then
> process the event in the call back. There is a sample program here that
> should
> make starting an analysis program very simple:
>
> https://fedorahosted.org/audit/browser/trunk/contrib/plugin
>
> > 2. it expects events in string format. I configured the plugin to send
> > events in binary format. hence auparse_next_event() was not returning.
>
> I'll update the man page to auparse_init to make sure this is clear.
>
> > 3. auparse_next_event() returns only when the parser sees the beginning
> of
> > the next event.. i.e first event is returned after seeing the beginning
> of
> > the 2nd event. Is this expected?
>
> Yes. For some types of events, we don't know when the event is complete
> until
> we see the next one. They can also be interlaced. Its on the TODO list to
> fix
> this second issue. But my suggestion is to look at a couple sample programs
> and follow how they do things.
>
> -Steve
>
>
> > On Wed, Jul 29, 2015 at 4:36 PM, Satish Chandra Kilaru <
> iam.kilaru at gmail.com
> > > wrote:
> > >
> > > Has anyone tried AUSOURCE_DESCRIPTOR with a unix socket as fd?
> > >
> > > I am doing the following.
> > >
> > > int sd_u = socket(AF_UNIX, SOCK_STREAM, 0);
> > > connect(sd_u, (struct sockaddr *) &sa, sizeof(sa))!=0)
> > > auparse_state_t *au = auparse_init(AUSOURCE_DESCRIPTOR, (const void
> > > *)sd_u);
> > > auparse_add_callback(au, auparse_callback, event_cnt, free);
> > > ausearch_next_event(au);
> > >
> > > My auparse_callback() is not getting called. My program just blocks in
> > > ausearch_next_event().
> > >
> > > read(sd_u, buf, sizeof(buf)) gets me events... That means I am using
> > > correct unix socket.
> > > How do I make the callback function to get called for each event?
> > >
> > > Am I missing something here?
> > >
> > > Thanks in advance.
> > > --Satish
> > > --
> > > Please Donate to www.wikipedia.org
>
>


-- 
Please Donate to www.wikipedia.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20150730/54e245c0/attachment.htm>


More information about the Linux-audit mailing list