On Friday 10 June 2005 17:38, Christoph Hellwig wrote:
> most of this looks like a copy & paste of the inotify code. Could you
> please arrange with the inotify folks to merge the patches?
>
Christoph,
Thank you for the response.
When we first started this project we had assessed whether or not inotify
would be a feasible starting point, but ultimately rejected it. What it came
down to was that the objectives of inotify were distinctly different from the
objectives of auditfs. These distinctions were rooted in the very design of
inotify. Why? Inotify is not a generic fs events notification subsystem.
Some of the cursory problems with using inotify which would need changing
were:
1) Coverage
Inotify is only interested in a portion of the fs ops that we are interested
in. Most notably, we need the ability to generate records every time the
[exec_]permission[_lite]() function is called.
2) Processing
The processing of events has to occur in the kernel, not in user space.
Inotify collects events and tosses them back over the fence for processing.
We cannot introduce any window of opportunity for audit subversion.
You see, auditfs is interested in the inode at location+name, whatever it may
be when the auditable event occurs. Thus, we've had to hook dcache to help
us with this processing. This is something Inotify does not care about nor
should it.
Inotify will resolve a path to its inode and watch _that_ inode, we're saying
"watch any inode at this path"
To build auditfs on top of inotify would require watching directories for
events on its children and processing the events in the kernel (and not
simply tossing them over the fence to user space). This gets very...
hackish ;)
3) Queue
Depending on the work, there may be a requirement that no audit record can be
lost. The message queue structure of inotify has the potential to overflow
and drop events. This is a no-go for us, but perfectly reasonable for
inotify.
To make this work for us we'd have to hook the queueing functions to forward
events on to the audit subsystem. This would basically mean fitting a system
that has been designed for interaction with userspace to also have
interaction with other parts of the kernel... again, hackish.
4) Context
We require information regarding the process and system call associated with
the fs event. This is not necessarily evident from where the event occurred
(ie: permission()). Inotify would have to hook into the audit subsystem to
get at this information.
The only place that the two projects converge is in fs/namei.c where they both
collect information about events. One project notifies the audit subsystem
and the other notifies user space. I think it is here where a collaboration
could take place without skewing the objectives of either project.
-tim
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
