Messages in this thread | | | From | Andreas Gruenbacher <> | Subject | Re: fanotify as syscalls | Date | Sat, 19 Sep 2009 00:00:43 +0200 |
| |
On Friday, 18 September 2009 22:52:08 Eric Paris wrote: > On Thu, 2009-09-17 at 22:07 +0200, Andreas Gruenbacher wrote: > > 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
| |