linux-kernel - Re: fanotify: the fscking all notification system

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <22424.1246368155@turing-police.cc.vt.edu>
Date:	Tue, 30 Jun 2009 09:22:35 -0400
From:	Valdis.Kletnieks@...edu
To:	Eric Paris <eparis@...hat.com>
Cc:	linux-kernel@...r.kernel.org, malware-list@...sg.printk.net
Subject: Re: fanotify: the fscking all notification system

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?

Content of type "application/pgp-signature" skipped