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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
