Re: key in syscall audit rules.

On Wed, 2005-05-18 at 10:28 -0500, Timothy R. Chavez wrote: Actually I'm entirely unconvinced that the keys on syscall rules are buying us anything at all. I wonder if we should just forget about adding them. With the file system watches, the key serves a real purpose -- it identifies the object which is accessed, because the logged action may have been performed via a hard link which we would not otherwise be able to associate with the original object being watched. With syscall watches, it doesn't tell us anything we don't already know; the fields which the different rules filter on are included in the log output anyway. Consider a case where we have two rules -- one of which will audit all network access by the 'exim' user, and another of which audits all outgoing connect() attempts. You can tell which audit records are generated by each criterion just by looking at fields which are already in the log, even _without_ adding keys to the syscall filtering rules. Also, there will be audit records which meet _both_ of the above criteria, and but unless we totally revamped the rule matching code you'd only ever see _one_ key per record. So you couldn't even trust the keys for filtering purposes when processing the logs. I think this is a solution in search of a problem -- unless someone can come up with a convincing use case for syscall rule keys, I think we should drop them. -- dwmw2