lkml.org 
[lkml]   [2008]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [malware-list] scanner interface proposal was: [TALPA] Intro linux interface for access scanning
From
Date
Eric Paris wrote on 2008-08-20 16:15:21:

> At the moment I'm leaning towards a separate async notification system
> for open/mtime change/close which will be a fire and forget notification
> system with no access control mechanism.
>
> A second, although very similar, mechanism will block on read/mmap
> (although I'm not so sure how to handle O_NONBLOCK without a kernel
> fastpath/inode marking that actually gets used, this is really a serious
> design issue with putting this at read/mmap. I don't think we are ready
> to give up on O_NONBLOCK for S_ISREG altogether just yet are we?) and
> provide access control. I also plan to include open() in the
> blocking/access control based on a /proc tunable. If applications can't
> handle EPERM at read/mmap they can get it at open and suffer the
> perf/blocking hit needlessly on open/stat sequences.

I think these are excellent ideas.

The kernel really does have to keep some record if it's going to do any
scanning from read() calls, it can't go to userspace each time to check
if a file is cached.
(It might be the single open file descriptor that's marked though)

O_NONBLOCK is then handled nicely, and we can avoid ever blocking that
client process (which given they're trying non-blocking IO is probably
a good thing).

--
Douglas Leeder



Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon,
OX14 3YP, United Kingdom.

Company Reg No 2096520. VAT Reg No GB 348 3873 20.



\
 
 \ /
  Last update: 2008-08-21 16:39    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site