Messages in this thread | | | From | Paul Moore <> | Date | Fri, 20 Apr 2018 12:13:37 -0400 | Subject | Re: [RFC PATCH ghak32 V2 05/13] audit: add containerid support for ptrace and signals |
| |
On Thu, Apr 19, 2018 at 9:03 PM, Richard Guy Briggs <rgb@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@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
| |