[RFC][PATCH 0/2] (#6 U2) filesystem auditing

[Timothy R. Chavez]

On Tuesday 29 March 2005 10:16 am, Stephen Smalley wrote:
> You likely need to explain why may_create is not adequate (i.e. no inode
> yet).  Although this almost makes me wonder whether i_audit should be
> d_audit, i.e. a field of the dentry, as your entire scheme is based on
> (parent directory, component name) pairs anyway.

For reason's we discussed on the phone it's probably best to keep the 
information stored at the inode level.

> Why MAY_WRITE|MAY_EXEC 
> here?  It is true that you would have checked search permission to the
> parent directory, but that is handled by your permission hook, and this
> is for the newly created inode, not the directory, right?

Sure, this makes sense.  I can pass a "0" here.

> Is there an 
> issue with regard to the fact that there will be no audit_notify_watch()
> call here if the create fails in the fs code?

Hm.  How about this:  I watch as root, /audit/foo (an ls on /audit reveals 
that it may only be written to by root).  Then, as a non-root user, I attempt 
to mv /home/chavezt/bar /audit/foo.  As expected, I'll fail, but no audit 
record will be generated.  

The rule is that we only receive records for a watched object once that object 
is, well, watched (ie: after it's been created, before its been destroyed, 
after it's moved in to, before it's moved out of, etc).  Thus, the burden of 
capturing failures is on the parent directory (which is intuitive right?).  
Doing so will generate records (from lstat, open, etc via our permissions' 
hook) about such failures.  Is this reasonable?

-tim