From: Eric Paris <eparis@redhat.com>
To: "Michael Morley, HCL America" <mmorley@hcl.in>
Cc: malware-list@lists.printk.net, linux-kernel@vger.kernel.org
Subject: RE: [malware-list] [RFC] 0/11 fanotify: fscking all notifiction andfile access system (intended for antivirus scanning and fileindexers)
Date: Tue, 07 Oct 2008 13:36:30 -0400 [thread overview]
Message-ID: <1223400990.2994.2.camel@localhost.localdomain> (raw)
In-Reply-To: <5CB739747AC639489F3E8210950C3E555C39EE@geousmail3.GEO.CORP.HCL.IN>
On Tue, 2008-10-07 at 10:32 -0700, Michael Morley, HCL America wrote:
> >
> > On Fri, 2008-09-26 at 23:05 -0700, david@lang.hm wrote:
> > > On Fri, 26 Sep 2008, Eric Paris wrote:
> > >
> > > > fanotify has 7 event types and only sends events for S_ISREG()
> files.
> > > > The event types are OPEN, READ, WRITE, CLOSE_WRITE, CLOSE_NOWRITE,
> > > > OPEN_ACCESS, and READ_ACCESS. Events OPEN_ACCESS and READ_ACCESS
> > > > require that the listener return some sort of allow/deny/more_time
> > > > response as the original process blocks until it gets an event (or
> > times
> > > > out.) listeners may register a group which will get notifications
> > about
> > > > any combination of these events. Antivirus scanners will likely
> want
> > > > OPEN_ACCESS and READ_ACCESS while file indexers would likely use
> the
> > > > non-ACCESS form of these events.
> > >
> > > sending a message out for every READ/WRITE seems like it will
> generate a
> > > LOT of messages, and very few will be ones that anyone cares about.
> > >
> > > one of the nice things about the TALPA approach was that there was
> an
> > > ability to notify only on a change of state (i.e. when a file that
> had
> > > been scanned was changed)
> > >
> > > this could do a similar thing, but I think it would be a much more
> > > expensive process to do it all in userspace.
> >
> > See the fastpath patch and explaination. Doesn't help for writes...
> >
>
> Eric, have you considered the scenario where the listening process
> appears to have stopped responding to access events? Under your design,
> the original process would be released after 5 seconds. Too many of
> these timeouts could wreak havoc on the OS. There should be some logic
> in fanotify to remove the fanotify_group after a certain number of
> timeouts which may or may not have to be sequential.
anyone have thoughts on the topic? Maybe I'll revisit it after I get a
new user interface. 25 missed permission events and I can just evict a
group altogether. Should the counter be cleared if a listener makes a
decision?
> Less importantly, it would be nice if the listening process could set
> the timeout value when it registers with fanotify (with some limits of
> course).
noted.
prev parent reply other threads:[~2008-10-07 17:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-26 21:07 [RFC] 0/11 fanotify: fscking all notifiction and file access system (intended for antivirus scanning and file indexers) Eric Paris
2008-09-26 21:34 ` Alan Cox
2008-09-26 21:48 ` [malware-list] " Greg KH
2008-09-26 22:03 ` Eric Paris
2008-10-02 19:24 ` Eric Paris
2008-10-02 20:48 ` Alan Cox
2008-09-27 6:05 ` david
2008-09-27 11:20 ` Alan Cox
2008-10-06 15:09 ` Pavel Machek
2008-09-27 14:04 ` Eric Paris
[not found] ` <5CB739747AC639489F3E8210950C3E555C39EE@geousmail3.GEO.CORP.HCL.IN>
2008-10-07 17:36 ` Eric Paris [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1223400990.2994.2.camel@localhost.localdomain \
--to=eparis@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=malware-list@lists.printk.net \
--cc=mmorley@hcl.in \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.