On Thu, Apr 19, 2018 at 9:03 PM, Richard Guy Briggs <rgb(a)redhat.com> wrote:
On 2018-04-18 20:32, Paul Moore wrote:
> On Fri, Mar 16, 2018 at 5:00 AM, Richard Guy Briggs <rgb(a)redhat.com> wrote:
...
> > /*
> > * audit_log_container_info - report container info
> > - * @tsk: task to be recorded
> > * @context: task or local context for record
> > + * @op: containerid string description
> > + * @containerid: container ID to report
> > */
> > -int audit_log_container_info(struct task_struct *tsk, struct audit_context
*context)
> > +int audit_log_container_info(struct audit_context *context,
> > + char *op, u64 containerid)
> > {
> > struct audit_buffer *ab;
> >
> > - if (!audit_containerid_set(tsk))
> > + if (!cid_valid(containerid))
> > return 0;
> > /* Generate AUDIT_CONTAINER_INFO with container ID */
> > ab = audit_log_start(context, GFP_KERNEL, AUDIT_CONTAINER_INFO);
> > if (!ab)
> > return -ENOMEM;
> > - audit_log_format(ab, "contid=%llu",
audit_get_containerid(tsk));
> > + audit_log_format(ab, "op=%s contid=%llu", op, containerid);
> > audit_log_end(ab);
> > return 0;
> > }
>
> Let's get these changes into the first patch where
> audit_log_container_info() is defined. Why? This inserts a new field
> into the record which is a no-no. Yes, it is one single patchset, but
> they are still separate patches and who knows which patches a given
> distribution and/or tree may decide to backport.
Fair enough. That first thought went through my mind... Would it be
sufficient to move that field addition to the first patch and leave the
rest here to support trace and signals?
I should have been more clear ... yes, that's what I was thinking; the
record format is the important part as it's user visible.
--
paul moore
www.paul-moore.com