Re: [PATCH] filesystem location based auditing
Amy Griffis wrote:
diff --git a/kernel/audit.c b/kernel/audit.c
index 4eb97b6..82d926e 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -552,6 +561,14 @@ static void audit_receive(struct sock *s
/* Initialize audit support at boot time. */
static int __init audit_init(void)
{
+ int i;
+
+ /* must be initialized before any audit_log calls */
+ for (i = 0; i < AUDIT_NR_FILTERS; i++) {
+ INIT_LIST_HEAD(&audit_filter_list[i].head);
+ spin_lock_init(&audit_filter_list[i].lock);
+ }
+
printk(KERN_INFO "audit: initializing netlink socket (%s)\n",
audit_default ? "enabled" : "disabled");
audit_sock = netlink_kernel_create(NETLINK_AUDIT, 0, audit_receive,
@@ -564,6 +581,11 @@ static int __init audit_init(void)
audit_initialized = 1;
audit_enabled = audit_default;
audit_log(NULL, GFP_KERNEL, AUDIT_KERNEL, "initialized");
+
+ audit_idev = inotify_init(audit_handle_ievent);
+ if (IS_ERR(audit_idev))
+ audit_panic("cannot initialize inotify device");
+
return 0;
}
__initcall(audit_init);
I don't mean to be too nit-picky, but what happens if the inotify_init()
call fails and audit_failure is anything but AUDIT_FAIL_PANIC? The same
sort of question, but with a little more immediacy, is also applicable
for the call to netlink_kernel_create(). If this routine fails, the
kernel may or may not panic, but if not, proceeds to use a NULL pointer
as if it were a valid pointer.
Perhaps while we're here, we could make the failure path a little more
defensive to keep the system from tipping over at some future point when
it tries use one of these pointers which are not supposed to be NULL,
but are?
Thanx...
ps