From mboxrd@z Thu Jan 1 00:00:00 1970 From: Klaus Weidner Subject: Re: [PATCH] IPC_SET_PERM cleanup Date: Tue, 9 May 2006 11:33:38 -0500 Message-ID: <20060509163338.GC31457@w-m-p.com> References: <445BB351.2040303@hp.com> <200605091121.21457.sgrubb@redhat.com> <4460B6A2.7060801@hp.com> <200605091155.34730.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mx1.redhat.com (mx1.redhat.com [172.16.48.31]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k49GY0kp013355 for ; Tue, 9 May 2006 12:34:00 -0400 Received: from mail.atsec.com (mail.atsec.com [195.30.252.105]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k49GXwcx005559 for ; Tue, 9 May 2006 12:33:58 -0400 Content-Disposition: inline In-Reply-To: <200605091155.34730.sgrubb@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On Tue, May 09, 2006 at 11:55:34AM -0400, Steve Grubb wrote: > I even updated the audit parsing specs to include all keywords: > http://people.redhat.com/sgrubb/audit/audit-parse.txt [...] > Does ouid and ogid not fit? I'd like us to define what we need in the parser > API and then use it in the audit messages. Ancilliary words like new, old, > last, first should not be tied with an underscore. If you find any, let me > know. The spec doesn't define what ancillary words are, the syntax it describes is that the audit record consists of key=value pairs. I think the options are the following: - adapt the spec to define ancillary words such as "new". - add the new_THING field names to the spec (and/or rename them to nTHING). - use unmodified THING field names, and use the record type name to disambiguate them. I dislike the ancillary words since it violates the key=value format (and the principle of least surprise), and it makes parsing more complex. Either of the other two options would be ok with me, but I agree with Steve that any new field names should be documented in the spec and not just added gratuitously. (Back in November I had proposed hierarchically structured audit records, which would have supported structs with named fields directly, but that discussion died in favor of ad-hoc printfs...) -Klaus