Re: [RFC][PATCH 0/2] (#6 U2) filesystem auditing
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