On Tue, Sep 14, 2021 at 9:15 AM Ondrej Mosnacek <omosnace(a)redhat.com> wrote:
The "key" field is used to associate records with the rule that
triggered them, os it's not a good idea to overload it with an
additional IPC key semantic. Moreover, as the classic "key" field is a
text field, while the IPC key is numeric, AVC records containing the IPC
key info actually confuse audit userspace, which tries to interpret the
number as a hex-encoded string, thus showing garbage for example in the
ausearch "interpret" output mode.
Hence, change it to "ipc_key" to fix both issues and also make the
meaning of this field more clear.
Signed-off-by: Ondrej Mosnacek <omosnace(a)redhat.com>
---
security/lsm_audit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Seems reasonable to me, I can merge it via the audit/next tree unless
James would prefer to take it via the LSM tree.
diff --git a/security/lsm_audit.c b/security/lsm_audit.c
index 5a5016ef43b0..1897cbf6fc69 100644
--- a/security/lsm_audit.c
+++ b/security/lsm_audit.c
@@ -224,7 +224,7 @@ static void dump_common_audit_data(struct audit_buffer *ab,
case LSM_AUDIT_DATA_NONE:
return;
case LSM_AUDIT_DATA_IPC:
- audit_log_format(ab, " key=%d ", a->u.ipc_id);
+ audit_log_format(ab, " ipc_key=%d ", a->u.ipc_id);
break;
case LSM_AUDIT_DATA_CAP:
audit_log_format(ab, " capability=%d ", a->u.cap);
--
2.31.1
--
paul moore
www.paul-moore.com