linux-kernel - Re: Issues with using fanotify for a filesystem indexer

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]

Date:	Fri, 27 Mar 2009 14:47:03 +0100
From:	Alexander Larsson <alexl@...hat.com>
To:	Al Viro <viro@...IV.linux.org.uk>
Cc:	eparis@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: Issues with using fanotify for a filesystem indexer

On Fri, 2009-03-27 at 13:02 +0000, Al Viro wrote:
> On Fri, Mar 27, 2009 at 01:47:23PM +0100, Alexander Larsson wrote:
> 
> > In order to write an app using the fanotify API satisfying the above
> > needs we would need the following events:
> > * the event queue overflowed, (you need to reindex everything)
> > * An inode was linked into the filesystem (creat, O_CREAT,
> > mkdir, link, symlink, etc)
> > * An inode was unlinked (unlink, rmdir, rename replaced existing file)
> > * An inode was moved in the filesystem (rename)
> 
> Erm...  Just how would you represent and *order* the events?  Note that
> "serialize all directory operations on given fs" is a non-starter...

This particular usecase doesn't really require a specific order for the
events. Its enough to know that something changed in a directory, or a
subtree. I can't think of an event reordering that would cause us to not
eventually reindex the files was affected by a change. 

Note, I don't think its possible to track renames precisely so that we
know that a previosly indexed file is in another place now, but rather
that if we move a directory from a to b we now need to fully reindex
both the a and b subtrees.

However, the order might be important for other usecases, I can't really
tell. Is it possible to give any kind of guarantee for the event order?

As for representation, I guess there are two issues here, how the event
looks in the kernel side event queue and how it looks to userspace. I'm
no kernel developer, but i guess a rename could be something liks

struct path *old_dir;
char *old_name
struct path *new_dir;
char *new_name

and the userspace side could be:

int old_dir_fd
char *old_name
int new_dir_fd
char *new_name

--
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/