[lkml]   [2014]   [Oct]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC][PATCH] audit: log join and part events to the read-only multicast log socket
On 14/10/07, Richard Guy Briggs wrote:
> On 14/10/07, Eric Paris wrote:
> > On Tue, 2014-10-07 at 14:23 -0400, Richard Guy Briggs wrote:
> > > Log the event when a client attempts to connect to the netlink audit multicast
> > > socket, requiring CAP_AUDIT_READ capability, binding to the AUDIT_NLGRP_READLOG
> > > group. Log the disconnect too.

> > super crazy yuck. audit_log_task_info() ??
> I agree. I already suggested that a while ago. I'd love to. sgrubb
> thinks it dumps way too much info. We still haven't got a definitive
> answer about what is enough and what is too much info for any given type
> of record.
> I also thought of moving audit_log_task() from auditsc.c to audit.c
> and using that. For that matter, both audit_log_task() and
> audit_log_task_info() could use audit_log_session_info(), but they are
> in slightly different order of keywords which will upset sgrubb's
> parser.
> What to do?
> Another paragraph I'd like to see added to
> would be a "canonical order" of keywords. However, that discussion went
> nowhere. Would it be reasonable to suggest only two possible orders
> instead of the almost infinite iterations possible and declare a
> standard order of keywords and gradually move to it?


Can we agree to *two* orders (instead of the full set of iterations) for
these keywords so that we can start to sort things in a canonical order?
This random order per type of audit log message is chaos.

> - 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

 \ /
  Last update: 2014-10-21 19:21    [W:0.188 / U:4.684 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site