mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Valdis.Kletnieks@vt.edu
To: Eric Paris <eparis@redhat.com>
Cc: linux-kernel@vger.kernel.org, malware-list@dmesg.printk.net
Subject: Re: fanotify: the fscking all notification system
Date: Tue, 30 Jun 2009 09:22:35 -0400	[thread overview]
Message-ID: <22424.1246368155@turing-police.cc.vt.edu> (raw)
In-Reply-To: Your message of "Mon, 29 Jun 2009 16:08:45 EDT." <1246306125.754.300.camel@dhcp235-23.rdu.redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1095 bytes --]

On Mon, 29 Jun 2009 16:08:45 EDT, Eric Paris said:

> fanotify provides two things:
> 1) a new notification system, sorta like inotify, only instead of an
> arbitrary 'watch descriptor' which userspace has to know how to map back
> to an object on the filesystem, fanotify provides an open read-only fd
> back to the original object.  It should be noted that the set of
> fanotify events is much smaller than the set of inotify events.
> 
> 2) an access system in which processes may be blocked until the fanotify
> userspace listener has decided if the operation should be allowed.

I don't care much about virus scanners - but some of us with petabytes of
disk space to manage could use tis for HSM applications.  The HSM daemon
could fanotify on the file, notice that the file accessed referred to a
special "I've been archived" stub/token, and put the file back before
giving the go-ahead to the process.

The only sticky question - does this happen early enough that the accessing
process, when un-blocked, will continue through open() and get the *new*
version of the newly restored file?

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

  reply	other threads:[~2009-06-30 14:36 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-29 20:08 Eric Paris
2009-06-30 13:22 ` Valdis.Kletnieks [this message]
2009-06-30 17:13   ` Bryan Donlan
2009-06-30 17:26   ` Eric Paris
2009-07-07 19:41     ` Valdis.Kletnieks
2009-07-07 20:57       ` Eric Paris
2009-07-01  4:10 ` Matt Helsley
2009-07-11 19:18   ` Sukadev Bhattiprolu
2009-07-02 15:02 ` Jan Engelhardt
2009-07-02 15:22   ` Eric Paris

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=22424.1246368155@turing-police.cc.vt.edu \
    --to=valdis.kletnieks@vt.edu \
    --cc=eparis@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=malware-list@dmesg.printk.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®