Re: fanotify as syscalls

On Tuesday, 22 September 2009 0:00:02 Jamie Lokier wrote:

Andreas Gruenbacher wrote:

quoted

On Monday, 21 September 2009 22:28:23 Jamie Lokier wrote:

quoted

It would be logical if fanotify could block and ack those [mount &
umount events] in the same way as it can block and ack other accesses
(with the usual filtering rules on which inodes trigger events, and
which don't or are cached).

Hmm. To me, fanotify is about file contents first of all: this is what
fanotify wants to be able to veto.

Surely you don't assume that what constitutes malicious content is
independent of it's location and/or name?

If the antimalware vendors want to base their decisions on pathnames then 
that's their decision, and they can check /proc/self/fd/N. We should be able 
to treat directory events the same.

(See also "echo 'run_virus&' >>.bash_login).

Wait a minute.  You don't assume that, otherwise why the interest in
subtrees? :-)

quoted

Directory events seem reasonable to add for inotify compatibility,

Did you see may point about userspace caches and how directory events
are fundamental to that - there's no way to build a cache without them?

Yes, there were some doubts about this appoach. Waiting for your code to 
demonstrate; an object based cache (e.g., st_dev + st_ino) rather than a 
pathname based cache would seem more reasonable.

quoted

but I see no need for access decisions on them.

Please excuse me; I'm a bit confused.  Is fanotify intended just for
use by access decision programs, or is the plan now for it to also be
a replacement for inotify?  I'm getting conflicting signals about
that.

Inotify doesn't support access decisions. So where's the problem with 
having "notify only" events for directory / mount / unmount events?

If it's just for access decision programs, and if those aren't going
to care about location, then there's no need to add directory events
to fanotify at all.  But then I'll be demanding subtree support in
inotify, please :-)

quoted

Even less so for mounts and unmounts.

   (as root) mkdir foo; mount dodgy foo -oloop; mount --bind foo/cat
/bin/cat

... and then someone accesses /bin/cat, which triggers a fanotify access 
decision.

Thanks,
Andreas