[lkml]   [2009]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 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:
    > > 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.


     \ /
      Last update: 2009-09-19 00:03    [W:0.036 / U:5.788 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site