On Thu, Jul 07, 2005 at 03:48:37PM -0400, Steve Grubb wrote:
On Thursday 07 July 2005 15:04, Greg KH wrote:
> You are adding auditfs, a new userspace access, right?
Not sure what you mean. This is using the same netlink interface that all the
rest of the audit system is using for command and control. Nothing has
changed here. What is different is the message I send into the kernel. The
audit system dispatches it into Tim's code which in turn sets up the watch.
What is auditfs for then?
> His email provided no documentation that I could see. Am I just
missing
> something?
The auditfs code is programmed by filling out the watch_transport structure
and sending a AUDIT_WATCH_INS message type. The perms, pathlen, & keylen are
all that's filled out. The path & key are stored back to back in the payload
section. To delete, you do the same thing and send AUDIT_WATCH_REM message.
Yes, this should be added to the documentation.
So how does userspace interact with auditfs?
Tim's code lets you say I want change notification to this file
only. The
notification follows the audit format with all relavant pieces of information
gathered at the time of the event and serialized with all other events.
That's great, and I understand the need for it. I just see all the
duplication between this effort and inotify, and know of Tim's
reluctance to want to work with inotify, and am objecting to that.
> Am I correct in thinking that you all need to split this patch
into two
> pieces, the new inode stuff, and auditfs, as neither one has anything to
> do with the other?
It could be split to make it easier to read, but one's useless without the
other.
Ok, some documentation about auditfs would go a long way toward
understanding this...
thanks,
greg k-h