From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: get_field_str() and interpret_field() bug with multi-word fields Date: Tue, 12 Aug 2008 15:16:08 -0400 Message-ID: <200808121516.08960.sgrubb@redhat.com> References: <0E43BF2D7491F0468B56B1A5C493866B020DD0F1@SAT4MX07.RACKSPACE.CORP> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <0E43BF2D7491F0468B56B1A5C493866B020DD0F1@SAT4MX07.RACKSPACE.CORP> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com Cc: William Kelly , Bret Piatt List-Id: linux-audit@redhat.com On Tuesday 12 August 2008 13:49:37 Jonathan Kelly wrote: > 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. =C2=A0I have verified that this issue exists in the C library, = as > well as the Python. =C2=A0I suspect that this may be an issue for multi= -word > fields in general, but have not noticed any other than 'op'. I am going to expose the encoder in libaudit in the next release so that=20 fields that have spaces can be escaped such that the parser can handle it= .=20 Since the next release or two will be going into RHEL5, any other changes= are=20 a non-starter.=20 -Steve