Re: fanotify as syscalls

On Friday, 18 September 2009 22:52:08 Eric Paris wrote:

On Thu, 2009-09-17 at 22:07 +0200, Andreas Gruenbacher wrote:

quoted

From my point of view, "global" events make no sense, and fanotify
listeners should register which directories they are interested in (e.g.,
include "/", exclude "/proc"). This takes care of chroots and namespaces
as well.

While I completely agree that most users don't want global events, the
antimalware vendors who today, unprotect and hack the syscall table on
their unsuspecting customer's machines to intercept every read, write,
open, close, mmap, etc syscall want EXACTLY that.

I understand that "global" is what those guys get today for lack of a 
reasonable mechanism, but it's not what anybody can ge given by fanotify: it 
conflicts with filesystem namespaces.

Consider running several "virtual machines" in separate namespaces on the same 
kernel. With "global" you are forced to run the same global fanotify 
listeners everywhere; with per-mount-point listeners, you can choose 
between "global" and something more fine-grained by identifying which 
vfsmounts you are interested in. (Filesystem namespaces correspond to 
vfsmount hierarchies.)

[...] You still have to exclude /proc and /sys and everything else.

Those are mount points, and so convenient to handle with a per-mount-point 
mechanism. No additional kernel code needed.

[...] Still though, this sounds like an issue for the f_type and f_fsid
exclusion syscall I say I'm still not settled on.

Those are also obsolete with a per-mount-point mechanism.

Thanks,
Andreas