From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Guy Briggs Subject: Re: [RFC][PATCH] audit: log join and part events to the read-only multicast log socket Date: Wed, 29 Oct 2014 17:09:59 -0400 Message-ID: <20141029210959.GN20866@madcap2.tricolour.ca> References: <30ef5c1ba42b52953e5684a0322975c3f0fadc77.1412706089.git.rgb@redhat.com> <1645943.LlOpH1gJUB@sifl> <20141022012405.GP15532@madcap2.tricolour.ca> <2257794.LVmDKq0bnE@sifl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <2257794.LVmDKq0bnE@sifl> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Paul Moore Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On 14/10/22, Paul Moore wrote: > On Tuesday, October 21, 2014 09:24:05 PM Richard Guy Briggs wrote: > > On 14/10/21, Paul Moore wrote: > > > Before we go to much farther, I'd really like us to agree that ordering is > > > not important, can we do that? As a follow up, what do we need to do to > > > make that happen in the userspace tools? > > > > At the very least, as I've suggested, agree on at least one more order, > > a canonical one, that can provide a much more firm guide how to present > > the keywords so that we're not stuck with an arbitrary order that turns > > out not to make sense for some reason or another. > > No, we're already seeing that a single fixed ordering is bad, adding an > alternate fixed ordering just kicks the can down the road a bit further and > sets a bad precedence for future development. It is time to get rid of the > fixed ordering in the audit records. The problem is that we don't just have a single fixed ordering. We have a different fixed ordering for each type of audit log message. This makes refactoring pretty much impossible or very inefficient at best. I agree that eliminating that dependency on ordering would be a great thing. This sounds like a great time to reference Postel's Law or Robustness Principle first introduced in IETF RFC760 and reworded in RFC1122: "Be conservative in what you send, be liberal in what you accept". > paul moore - RGB -- Richard Guy Briggs Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat Remote, Ottawa, Canada Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545