auparse question

auparse question

[LC Bruzenak]

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

Re: auparse question

[Miloslav Trmač]

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

Re: auparse question

[LC Bruzenak]

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

audit string encoding is broken (Was: auparse question)

[John Dennis]

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).
>
> 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.
>   
I wonder how many times on this list someone has pointed out that the 
encoding
of string values in the audit subsystem is BROKEN?

How many times will people stumble on this before it gets fixed?

String encoding has to get fixed in the kernel first because that is 
where the string
values are generated.

There have been numerous emails on this list explaining the problem in 
detail
and numerous proposals for easy fixes.

-- 
John Dennis <jdennis@redhat.com>

Re: audit string encoding is broken (Was: auparse question)

[LC Bruzenak]

On Fri, 2008-06-06 at 16:07 -0400, John Dennis wrote:
> 
> String encoding has to get fixed in the kernel first because that is 
> where the string values are generated.

Well, as in my case, there are those of us talented enough to stumble on
our own userspace-generated strings, submitted via
audit_log_user_message()...

LCB.

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

auparse question

[LC Bruzenak]

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

auparse question

[LC Bruzenak]

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

Re: auparse question

[Miloslav Trmac]

----- 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

Re: auparse question

[Steve Grubb]

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

Re: auparse question

[Steve Grubb]

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

Re: auparse question

[LC Bruzenak]

> 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