On 5/21/2021 1:19 PM, Paul Moore wrote: <snip> and trim the CC list. > Okay, we've got a disconnect here regarding "audit contexts" and > "local contexts", skip down below where I attempt to explain things a > little more but basically if there is a place that uses this pattern: > > audit_log_start(audit_context(), ...); This pattern isn't helpful. audit_context() returns NULL in about 1 of 4 calls. All of these callers of audit_context() get a NULL result some of the time. getname_kernel debugfs_create_dir tracefs_create_file vfs_fchown do_settimeofday64 bprm_execve ksys_mmap_pgoff move_addr_to_kernel __do_pipe_flags __do_sys_capset syscall_trace_enter cap_bprm_creds_from_file load_module __x64_sys_fsetxattr bpf_prog_load audit_signal_info_syscall sel_write_enforce common_lsm_audit audit_set_loginuid __dev_set_promiscuity ipcperms devpts_pty_new > ... you don't need, or want, a "local context". You might need a > local context if you see the following pattern: > > audit_log_start(NULL, ...); > > The "local context" idea is a hack and should be avoided whenever > possible; if you have an existing audit context from a syscall, or > something else, you *really* should use it ... or have a *really* good > explanation as to why you can not. Almost all audit events want to record the subject context by calling audit_log_task_context(). If multiple contexts need to be recorded there has to be a separate record, which means there has to be an audit context. The only case where an audit context is reliably available is in syscalls. Hence, a "local context" for many of the cases where the first argument to audit_log_start() would otherwise be NULL, either explicitly or because audit_context() returns NULL. Is there some other way to synchronize the "timestamp" without use of an audit context? My understanding is that this is the primary purpose of the audit context.
