All of lore.kernel.org
 help / color / mirror / Atom feed
* auparse question
@ 2011-08-30 21:12 LC Bruzenak
  2011-08-30 23:18 ` Miloslav Trmac
  2011-08-31 16:49 ` Steve Grubb
  0 siblings, 2 replies; 9+ messages in thread
From: LC Bruzenak @ 2011-08-30 21:12 UTC (permalink / raw)
  To: Linux Audit

I'm using auparse_get_field_type from the parse lib.
The return value for error is "0" which is also that of the AUDIT_PID
field.

Right? I am getting some errors that thought they were PIDs.

Thx,
LCB

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: auparse question
  2011-08-30 21:12 auparse question LC Bruzenak
@ 2011-08-30 23:18 ` Miloslav Trmac
  2011-08-31 18:29   ` Steve Grubb
  2011-08-31 16:49 ` Steve Grubb
  1 sibling, 1 reply; 9+ messages in thread
From: Miloslav Trmac @ 2011-08-30 23:18 UTC (permalink / raw)
  To: LC Bruzenak; +Cc: Linux Audit

----- Original Message -----
> I'm using auparse_get_field_type from the parse lib.
> The return value for error is "0" which is also that of the AUDIT_PID
> field.
> 
> Right? I am getting some errors that thought they were PIDs.
The return value of auparse_get_field_type() is a value from auparse_type_t defined in auparse-defs.h.  0 is AUPARSE_TYPE_UNCLASSIFIED (i.e. "there is no current field, or we don't know what kind of data is in the field").  AUPARSE_TYPE_* and the AUDIT_* field enums both deal with fields, but are distinct.  It is somewhat confusing I'm afraid.
   Mirek

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: auparse question
  2011-08-30 21:12 auparse question LC Bruzenak
  2011-08-30 23:18 ` Miloslav Trmac
@ 2011-08-31 16:49 ` Steve Grubb
  1 sibling, 0 replies; 9+ messages in thread
From: Steve Grubb @ 2011-08-31 16:49 UTC (permalink / raw)
  To: linux-audit

On Tuesday, August 30, 2011 05:12:17 PM LC Bruzenak wrote:
> I'm using auparse_get_field_type from the parse lib.
> The return value for error is "0" which is also that of the AUDIT_PID
> field.
> 
> Right? I am getting some errors that thought they were PIDs.

That does seem to be a mistake in the API. As a workaround for this, you can check for 
an error with auparse_get_record_text() == NULL. I suppose I could fix the problem 
going forward by making auparse_get_type() return -1 on error.

-Steve

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: auparse question
  2011-08-30 23:18 ` Miloslav Trmac
@ 2011-08-31 18:29   ` Steve Grubb
  0 siblings, 0 replies; 9+ messages in thread
From: Steve Grubb @ 2011-08-31 18:29 UTC (permalink / raw)
  To: linux-audit; +Cc: Miloslav Trmac

On Tuesday, August 30, 2011 07:18:02 PM Miloslav Trmac wrote:
> ----- Original Message -----
> > I'm using auparse_get_field_type from the parse lib.
> > The return value for error is "0" which is also that of the AUDIT_PID
> > field.
> > 
> > Right? I am getting some errors that thought they were PIDs.
> 
> The return value of auparse_get_field_type() is a value from auparse_type_t
> defined in auparse-defs.h.

Right. AUDIT_PID is an event record type which would be returned by 
auparse_get_type(). If you look in auparse.h, you can see the groupings of functions 
that access event level, record level, and field level components.


> 0 is AUPARSE_TYPE_UNCLASSIFIED (i.e. "there is
> no current field, or we don't know what kind of data is in the field"). 

Yes, but the intent of AUPARSE_TYPE_UNCLASSIFIED is to say that the field contains data 
that needs no special cross reference or conversion to be human readable (or as you 
say we don't know about the field). This is different from returning something to say 
that you are not pointed at a valid field - i.e. you ran off the end. From what I can 
tell, you can only get the error if you are moving the internal pointer around without 
checking return codes. There really is an unintended API mistake in there. :)


> AUPARSE_TYPE_* and the AUDIT_* field enums both deal with fields, but are
> distinct.  It is somewhat confusing I'm afraid.

Maybe looking at the auparse.h file clarifies a few things since they are grouped?

-Steve

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: auparse question
@ 2011-08-31 18:07 LC Bruzenak
  0 siblings, 0 replies; 9+ messages in thread
From: LC Bruzenak @ 2011-08-31 18:07 UTC (permalink / raw)
  To: Linux Audit

> That does seem to be a mistake in the API. As a workaround for this, 
...

Thanks Steve,

Per Mirek, I just changed to look for the AUPARSE_TYPE_* enum for
checking the return and it is fine now. 

LCB
-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

^ permalink raw reply	[flat|nested] 9+ messages in thread

* auparse question
@ 2011-08-30 21:09 LC Bruzenak
  0 siblings, 0 replies; 9+ messages in thread
From: LC Bruzenak @ 2011-08-30 21:09 UTC (permalink / raw)
  To: Linux Audit

I am using the parse library, calling auparse_get_type.
It returns a 0 on failure, which I believe is also the integer value for
AUDIT_PID.

Is this correct or am I missing somethng?

Thx,
LCB

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: auparse question
  2008-06-06 19:36 ` Miloslav Trmač
@ 2008-06-06 19:53   ` LC Bruzenak
  0 siblings, 0 replies; 9+ messages in thread
From: LC Bruzenak @ 2008-06-06 19:53 UTC (permalink / raw)
  To: Miloslav Trmač; +Cc: Linux Audit

On Fri, 2008-06-06 at 19:36 +0000, Miloslav Trmač wrote:
...
> One usual way of handling spaces is to use the hex-encoded form for
> field representation, and decode it either using
> auparse_interpret_field() (which hard-codes the ways to decode specific
> field types, and does nothing for unknown types), or in the application.
> The other usual way of handling spaces is to just write them in the
> record and let the applications deal with them however they want (you
> can get the raw record text out of auparse, after all).

Fair enough; thanks for the response. 
Yes, I am able to get the raw string out and I can sub-parse it myself.
Up to this point the parser was doing all the work for me! :)

Thx!
LCB.

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: auparse question
  2008-06-06 19:20 LC Bruzenak
@ 2008-06-06 19:36 ` Miloslav Trmač
  2008-06-06 19:53   ` LC Bruzenak
  0 siblings, 1 reply; 9+ messages in thread
From: Miloslav Trmač @ 2008-06-06 19:36 UTC (permalink / raw)
  To: LC Bruzenak; +Cc: Linux Audit

LC Bruzenak píše v Pá 06. 06. 2008 v 14:20 -0500:
> I send in my own n=v pairs.
> The auparse library code returns all the name elements but on a string
> value with embedded spaces it stops at the first space.
<snip>
> I read through most of the list entries regarding this and also Steve's
> auparse text page and I must be missing the answer; apology in advance
> since after reading through most of the replies I realized it has been
> discussed thoroughly, but I do not see the answer.
There's no answer.  auparse (except for some special cases) splits
fields at spaces.

One usual way of handling spaces is to use the hex-encoded form for
field representation, and decode it either using
auparse_interpret_field() (which hard-codes the ways to decode specific
field types, and does nothing for unknown types), or in the application.
The other usual way of handling spaces is to just write them in the
record and let the applications deal with them however they want (you
can get the raw record text out of auparse, after all).

I plan to make auparse more useful in this regard, but the best I can
hope for is adding more special cases for specific field and record
types.  A long-term, future-proof solution must involve some changes to
the record format definition.
	Mirek

^ permalink raw reply	[flat|nested] 9+ messages in thread

* auparse question
@ 2008-06-06 19:20 LC Bruzenak
  2008-06-06 19:36 ` Miloslav Trmač
  0 siblings, 1 reply; 9+ messages in thread
From: LC Bruzenak @ 2008-06-06 19:20 UTC (permalink / raw)
  To: Linux Audit

I have successfully sent in a AUDIT_TRUSTED_APP user audit event &
viewed that message picked off the stream by audisp.

I send in my own n=v pairs.
The auparse library code returns all the name elements but on a string
value with embedded spaces it stops at the first space.

On the sending side I have tried escaping double-quotes, single-quotes,
and escaped single-quotes.

I read through most of the list entries regarding this and also Steve's
auparse text page and I must be missing the answer; apology in advance
since after reading through most of the replies I realized it has been
discussed thoroughly, but I do not see the answer.

I also copied the example in the  auparse_feed manpage, compiled that
and tried to put some data into a file for an easy example. I cannot
seem to get the right format in my event data file however. If someone
has an example of that file data it would help, since I'd ideally like
to use this setup for quick testing.

Thx,
LCB.

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2011-08-31 18:29 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-08-30 21:12 auparse question LC Bruzenak
2011-08-30 23:18 ` Miloslav Trmac
2011-08-31 18:29   ` Steve Grubb
2011-08-31 16:49 ` Steve Grubb
  -- strict thread matches above, loose matches on Subject: below --
2011-08-31 18:07 LC Bruzenak
2011-08-30 21:09 LC Bruzenak
2008-06-06 19:20 LC Bruzenak
2008-06-06 19:36 ` Miloslav Trmač
2008-06-06 19:53   ` LC Bruzenak

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.