>
> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |