[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [RFC][PATCH] new audit rule interface



On Mon, 2005-12-19 at 11:41 -0500, Amy Griffis wrote:
> On Thu, Dec 15, 2005 at 02:34:32PM -0600, Dustin Kirkland wrote:
> > You touch on this a bit later...  Ideally, I think it would be nice not
> > to bitmask into the upper bits of each field[] entry.  I would prefer
> > another integer array fieldflags[] where things such as the
> > audit_operator and whatever else might live.  That would give us a full
> > 32 bits to mask against per field, and not cut into the total bits
> > available for field[] values.
> 
> How about this?
> 
> struct audit_rule_xprt {
> 	__u32		flags;	/* AUDIT_PER_{TASK,CALL}, AUDIT_PREPEND */
> 	__u32		action;	/* AUDIT_NEVER, AUDIT_POSSIBLE, AUDIT_ALWAYS */
> 	__u32		field_count;
> 	__u32		mask[AUDIT_BITMASK_SIZE];
> 	__u32		fields[AUDIT_MAX_FIELDS];
> 	__u32		values[AUDIT_MAX_FIELDS];
> 	__u32		flags[AUDIT_MAX_FIELDS];
> 	__u32		version; /* data structure version */
> 	__u32		pad[4];	 /* reserved for future use */
> 	__u32		buflen;	 /* total length of string fields */
> 	char		buf[0];  /* string fields buffer */
> };
> 
> In addition to the fields needed for passing strings, I added a
> per-field flags array, version, and padding for future fields.

Two things...

1) This shows a "__u32 flags" field and a "__u32
flags[AUDIT_MAX_FIELDS]" field.  That's not going to fly.  Perhaps
fieldflags[AUDIT_MAX_FIELDS] instead?

2) I'm not a big fan of the pad[4] for future use, but that's just me.
It's arbitrarily sized and I would surmise that plenty of arguing will
ensue as someone tries to use those 16 bytes.  


:-Dustin

Attachment: signature.asc
Description: This is a digitally signed message part


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]