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

Re: fanotify as syscalls

From: Eric Paris <eparis@redhat.com>
Date: 2009-09-22 16:12:25
Also in: linux-fsdevel, lkml

On Tue, 2009-09-22 at 17:31 +0200, Andreas Gruenbacher wrote:
On Tuesday, 22 September 2009 16:51:39 Davide Libenzi wrote:
quoted
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: 
That's not the fatal flaw.  The fatal flaw is that I am not going to
write 90% of a rootkit and make it easy to use.  Not going to happen.
There's a reason we went to the trouble to mark the syscall call RO, we
don't export it, and we don't want people playing with it.  It clearly
would have been the quickest, easiest, and fastest way to make
anti-virus companies happy, but it doesn't really solve a good problem
and it leaves all of us in a worse position than we are today.  Easy !=
Good.

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