From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Dennis Subject: audit string encoding is broken (Was: auparse question) Date: Fri, 06 Jun 2008 16:07:18 -0400 Message-ID: <484998F6.7080604@redhat.com> References: <1212780014.6726.26.camel@homeserver> <1212781001.15953.12.camel@amilo> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <1212781001.15953.12.camel@amilo> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: =?UTF-8?B?TWlsb3NsYXYgVHJtYcSN?= Cc: Linux Audit List-Id: linux-audit@redhat.com Miloslav Trma=C4=8D 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. > =20 I wonder how many times on this list someone has pointed out that the=20 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=20 where the string values are generated. There have been numerous emails on this list explaining the problem in=20 detail and numerous proposals for easy fixes. --=20 John Dennis