On Monday, October 16, 2017 7:04:14 PM EDT Richard Guy Briggs wrote: > On 2017-10-16 22:28, Steve Grubb wrote: > > On Monday, October 16, 2017 6:06:47 PM EDT Steve Grubb wrote: > > > > > +/* Log information about who is connecting to the audit multicast > > > > > socket > > > > > */ +static void audit_log_multicast_bind(int group, const char *op, > > > > > int > > > > > err) +{ > > > > > + const struct cred *cred; > > > > > + struct tty_struct *tty; > > > > > + char comm[sizeof(current->comm)]; > > > > > + struct audit_buffer *ab; > > > > > + > > > > > + ab = audit_log_start(NULL, GFP_KERNEL, > > > > > AUDIT_EVENT_LISTENER); > > > > > > > > It really seems like this should be associated with the current task, > > > > e.g. "audit_log_start(current->audit_context, ...)". After all, the > > > > whole point of this record is to capture information about the subject > > > > who is binding to the multicast socket. > > > > > > OK, easy enough. > > > > But wouldn't that make it an auxiliary record (if there happens to be a > > syscall record) instead of a standalone event? The intention is that this > > event is standalone just like AUDIT_SECCOMP or AUDIT_LOGIN. Associating > > with the current task is done by using current in formatting the message > > as seen below. (e.g. task_pid_nr(current), audit_get_sessionid(current)) > > > > I think it's correct as is. > > Yes, this would associate this record with the tentatively generated > SYSCALL record for this task.
OK, then my secondary assessment was right. The patch in this hunk is fine. This is a standalone event. I have a patch ready with the .bind/.unbind function pointers grouped together. I can add the ghak issue easily enough. I just need a ruling on what define number to use for AUDIT_EVENT_LISTENER. Should it be 1331 or 1332 (which is its actual number)? -Steve -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit