Re: [PATCH] audit: file system auditing based on location and name

From: Greg KH
Date: Fri Jul 08 2005 - 12:55:50 EST


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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/