Re: [PATCH] audit: file system auditing based on location and name

[Arjan van de Ven]

> 
> Some notable implementation details are as follows:
> 
>   * struct inode is _not_ extended to associate audit data with the
>     inode.  A hash table is used in which the inode is hashed to 
>     retrieve its audit data.  We know if an inode has audit data
>     if I_AUDIT has been turned on in inode->i_state.

why is this? It would be a very logical thing to store this stuff inside
the inode. It sounds like a bad design to keep per inode data out of the
inode. (if you're concerned about taking a lot of space, put a pointer
to a kmalloc()'d piece of memory into the inode instead). A hash is
just, well, odd for this.

>   * Inodes with audit data are implicitly pinned in memory when 
>     I_AUDIT is turned on in inode->i_state.  This prevents an
>     auditable incore inode from being pushed out of the icache,
>     preserving auditability even under memory pressures.

sounds like inotify then... 


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/