Thread (82 messages) flat view 82 messages, 15 authors, 2009-09-23

Re: fanotify as syscalls

From: Andreas Gruenbacher <hidden>
Date: 2009-09-22 15:31:34
Also in: linux-fsdevel, lkml

On Tuesday, 22 September 2009 16:51:39 Davide Libenzi wrote:
On Tue, 22 Sep 2009, Jamie Lokier wrote:
quoted
I don't mind at all if fanotify is replaced by a general purpose "take
over the system call table" solution ...
That was not what I meant ;)
You'd register/unregister as syscall interceptor, receiving syscall number
and parameters, you'd be able to return status/error codes directly, and
you'd have the ability to eventually change the parameters. All this
should be pretty trivial code, and at the same time give full syscall
visibility to the modules.
The fatal flaw of syscall interception is race conditions: you look up a 
pathname in your interception layer; then when you call into the proper 
syscall, the kernel again looks up the same pathname. There is no way to 
guarantee that you end up at the same object in both lookups. The security 
and fsnotify hooks are placed in the appropriate spots to avoid exactly that.

Andreas
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help