From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Dennis Subject: Re: [PATCH] Fix acct quoting in audit_log_acct_message()) Date: Tue, 04 Mar 2008 15:57:46 -0500 Message-ID: <47CDB7CA.5090608@redhat.com> References: <47CCC6F0.1090005@redhat.com> <47CD65A3.8020204@redhat.com> <1204654248.12783.32.camel@vespa.frost.loc> <200803041356.19571.sgrubb@redhat.com> <47CDB116.7010007@redhat.com> <1204662990.12783.35.camel@vespa.frost.loc> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1204662990.12783.35.camel@vespa.frost.loc> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Tomas Mraz Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com Tomas Mraz wrote: > But even if the messages were parsable into a tree regardless of kernel > version, for semantic understanding of the messages you'll still have to > know which kernel generated them unless the semantics is set in stone > for all possible messages. Parsing and semantic interpretation are two distinct operations, both have merit. A library should be able to parse the data stream without producing errors. This is not an abstract issue for me, I had to fix bugs which threw serious exceptions because it could not determine if a value was a string or binary data (e.g. hexadecimal encoded string). When it made the wrong decision and tried to decode what it thought was hexadecimal encoding it produced a horribly malformed string which violated UTF-8, which then sent every library which was passed the string into the weeds. Which by the way would include any library which might try to interpret the semantic meaning of the string. FWIW, I do not consider the ability to recognize a string as semantic interpretation. Semantic interpretation would be interpreting the string. Recognizing a string in a byte orientated data stream is parsing. -- John Dennis