]> asedeno.scripts.mit.edu Git - linux.git/commit
audit: give a clue what CONFIG_CHANGE op was involved
authorRichard Guy Briggs <rgb@redhat.com>
Mon, 10 Dec 2018 22:17:48 +0000 (17:17 -0500)
committerPaul Moore <paul@paul-moore.com>
Mon, 14 Jan 2019 21:40:31 +0000 (16:40 -0500)
commit53fc7a01df51f58b317ea5ab1607a1af65d6d4cf
tree47496488683a4ea541f87958c7ef987ca36c3cb3
parentbfeffd155283772bbe78c6a05dec7c0128ee500c
audit: give a clue what CONFIG_CHANGE op was involved

The failure to add an audit rule due to audit locked gives no clue
what CONFIG_CHANGE operation failed.
Similarly the set operation is the only other operation that doesn't
give the "op=" field to indicate the action.
All other CONFIG_CHANGE records include an op= field to give a clue as
to what sort of configuration change is being executed.

Since these are the only CONFIG_CHANGE records that that do not have an
op= field, add them to bring them in line with the rest.

Old records:
type=CONFIG_CHANGE msg=audit(1519812997.781:374): pid=610 uid=0 auid=0 ses=1 subj=... audit_enabled=2 res=0
type=CONFIG_CHANGE msg=audit(2018-06-14 14:55:04.507:47) : audit_enabled=1 old=1 auid=unset ses=unset subj=... res=yes

New records:
type=CONFIG_CHANGE msg=audit(1520958477.855:100): pid=610 uid=0 auid=0 ses=1 subj=... op=add_rule audit_enabled=2 res=0

type=CONFIG_CHANGE msg=audit(2018-06-14 14:55:04.507:47) : op=set audit_enabled=1 old=1 auid=unset ses=unset subj=... res=yes

See: https://github.com/linux-audit/audit-kernel/issues/59

Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
[PM: fixed checkpatch.pl line length problems]
Signed-off-by: Paul Moore <paul@paul-moore.com>
kernel/audit.c