From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Dennis Subject: Re: get_field_str() and interpret_field() bug with multi-word fields Date: Tue, 12 Aug 2008 14:52:27 -0400 Message-ID: <48A1DBEB.1080501@redhat.com> References: <0E43BF2D7491F0468B56B1A5C493866B020DD0F1@SAT4MX07.RACKSPACE.CORP> <1218564336.7022.72.camel@homeserver> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0192769891==" Return-path: In-Reply-To: <1218564336.7022.72.camel@homeserver> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: LC Bruzenak Cc: William Kelly , Bret Piatt , Linux-audit@redhat.com List-Id: linux-audit@redhat.com This is a multi-part message in MIME format. --===============0192769891== Content-Type: multipart/alternative; boundary="------------090102020801040208060101" This is a multi-part message in MIME format. --------------090102020801040208060101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit LC Bruzenak wrote: > On Tue, 2008-08-12 at 12:49 -0500, Jonathan Kelly wrote: > >> Hello, >> >> >> >> When using the python auparse library to call >> AuParser.interpret_field() on a multi-word field, only the first word >> in the field is returned. Using get_field_str() instead of >> interpret_field() yields the same output. I have verified that this >> issue exists in the C library, as well as the Python. I suspect that >> this may be an issue for multi-word fields in general, but have not >> noticed any other than 'op'. >> >> >> > > Line forms here...see the following thread: > https://www.redhat.com/archives/linux-audit/2008-June/msg00005.html > > LCB. > > The line started a while ago ... https://www.redhat.com/archives/linux-audit/2008-January/msg00082.html (the discussion "While we're at it" is irrelevant to the current topic) FWIW, I think the proper encoding should be that all string values are enclosed in double quotes and the string encoding follows the same backslash escaping defined for the C language which was subsequently adopted by many other system components which would make it instantly familiar and parseable by many tools. This would be a very simple and welcome fix. More complaints here: https://www.redhat.com/archives/linux-audit/2008-June/msg00009.html -- John Dennis --------------090102020801040208060101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit LC Bruzenak wrote: 
On Tue, 2008-08-12 at 12:49 -0500, Jonathan Kelly wrote:
  
Hello,

 

When using the python auparse library to call
AuParser.interpret_field() on a multi-word field, only the first word
in the field is returned.  Using get_field_str() instead of
interpret_field() yields the same output.  I have verified that this
issue exists in the C library, as well as the Python.  I suspect that
this may be an issue for multi-word fields in general, but have not
noticed any other than 'op'.

 
    

Line forms here...see the following thread:
https://www.redhat.com/archives/linux-audit/2008-June/msg00005.html

LCB.
The line started a while ago ...

https://www.redhat.com/archives/linux-audit/2008-January/msg00082.html
(the discussion "While we're at it" is irrelevant to the current topic)

FWIW, I think the proper encoding should be that all string values are enclosed in double quotes and the string encoding follows the same backslash escaping defined for the C language which was subsequently adopted by many other system components which would make it instantly familiar and parseable by many tools. This would be a very simple and welcome fix.

More complaints here:
https://www.redhat.com/archives/linux-audit/2008-June/msg00009.html


-- 
John Dennis <jdennis@redhat.com>
--------------090102020801040208060101-- --===============0192769891== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============0192769891==--