linux-kernel - Re: [RFC PATCH -v4 00/14] fsnotify, dnotify, and inotify

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: <c6d9bea0812181536p2a3aaeacmbd6af0474279b7b@mail.gmail.com>
Date:	Thu, 18 Dec 2008 18:36:36 -0500
From:	"C. Scott Ananian" <cscott@...top.org>
To:	"Eric Paris" <eparis@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH -v4 00/14] fsnotify, dnotify, and inotify

On Fri, Dec 12, 2008 at 4:51 PM, Eric Paris <eparis@...hat.com> wrote:
> The following series implements a new generic in kernel filesystem
> notification system, fsnotify.  On top of fsnotify I reimplement dnotify and
> inotify.  I have not finished with the change from inotify although I think
> inotify_user should be completed.  In kernel inotify users (aka audit) still
> (until I get positive feedback) relay on the old inotify backend.  This can be
> 'easily' fixed.
> All of this is in preperation for fanotify and using fanotify as an on access
> file scanner.   So you better know it's coming.
> Why is this useful?  Because I actually shrank the struct inode.  That's
> right, my code is smaller and faster.  Eat that.

As a desktop-search-and-indexing developer, it doesn't seem like
fanotify is going to give me anything I want.  The inotify/dnotify
restructuring to fsnotify seems reasonable, but not exciting (to me).

>From a desktop search perspective, my wishlist reads like this:
 1) An 'autoadd' option added to inotify directory watches, so that
newly-created subdirectories get atomically added to the watch.  That
would prevent missed IN_MOVED_FROM and IN_MOVED_TO in a newly created
directory.
 2) A reasonable interface to map inode #s to "the current path to
this inode" -- or failing that, an iopen or ilink syscall.  This would
allow the search index to maintain inode #s instead of path names for
files, which saves a lot of IN_MOVE processing and races (especially
for directory moves, which require recursive path renaming).
 3) Dream case: in-kernel dirty bits.  I don't *really* want to know
all the details; I just want to know which inotify watches are dirty,
so I can rescan them.  To avoid races, the query should return a dirty
watch and atomically clear its dirty flag, so that if it is updated
again during my indexing, I'd be told to scan it again.

>From the indexing perspective, dealing with a sequence of operations like:
   1) mkdir -p abc/def
   2) echo "foo" > abc/def/ghi
   3) mv abc xyz
   4) mv xyz/def/ghi jkl
is entirely too much "fun".  Depending on the races between kernel and
user space, I might get only:
   CREATE abc
   IN_MOVED_TO jkl
and if I do get my watches put in place after step (1) I've still got
to deal with a recursive rename in step (3), the possibility of
getting notification of (2) after the rename in (3) (so abc/def/ghi no
longer exists), and other delights.

As far as I can tell, fanotify only helps with the 'recursive watch'
problem (which could be solved with 'autoadd' or just using the
algorithm in http://mail.gnome.org/archives/dashboard-hackers/2004-October/msg00022.html
), and doesn't give me any tools to deal with the actual hard races or
path-maintenance problems.
  --scott

-- 
                         ( http://cscott.net/ )
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/