[audit-discuss] Pathname auditing issue

[Tomas Zeman]

On Tue, Jan 23, 2007 at 03:35:05PM +0100, Jan Pechanec wrote:
 
> 	I wouldn't say it's a bug. This is consistent at least. Imagine an 
> application that uses path token as well in higher-level audit events. Such 
> application can't see that somebody else renamed the file (unless it will 
> use something like PSARC/2007/027) so it will use the old name.

You're right, that is consistent.

But in case of a symlink, for example, syscall audit for open() etc. writes the
resolved pathname while it is up to the application which path will write into
audit (resolved or symlink).


> 
> 	I guess there is no problem for rename to change the path in all 
> audit structures for all open file descriptors for that file (I gues it must 
> work in this or similar way). However, imagine you have 10000 fd's from the 
> same file, you would have to gain an exclusive lock for the whole operation 
> of changing those 10000 filenames. Otherwise someone else could read from fd 
> 9999 whose filename in audit structure wasn't still updated and again - it 
> wouldn't be consistent.

Exactly and that is why each file has its own audit specific data, ie. audit
system has its own cache for filenames (and other things). 

My motivation was to use vnode/v_path information which is global, can be
updated on renames and getting rid off the audit pathname caching. That would
gain performance and reduce memory used by the audit (also CR 5010377 auditing
should take advantage of vnode path information).

So the question is: how to describe a vnode state (and associated file
descriptor) in the audit trail? Path and attributes seem to be natural way and
that is how it works now. But if a file is renamed or deleted audit trail can
contain different paths for the same vnode at the same time (if used in
different processes). Is that consistent? From the point of vnode, not. From
the point of application, yes (because it opened file "A", reads it and closes
it, so it is file "A", even though at the same time it is file "B" already - if
somebody stat()s that file).

> 
> 	also imagine this with the changed audit code:
> 
> 	fa = create-open A
> 	fb = open B
> 	read A
> 	read B
> 	delete A
> 	rename B -> A
> 	close fa
> 	close fb
> 
> 	now both audit records for close would have "path A" which would 
> denote two different files. It can be also confusing. Of course, from audit 
> log analysis everything can be read which is true for the case you 
> described, too.
> 	
> 	my opinion is that current situation is fine.
> 
Thanks, 

tomas