LWN: Comments on "Another new ABI for fanotify"

Fanotify has a bug in 3.1 or below

searockcliff — Wed, 12 Oct 2011 03:23:07 +0000

Fanotify has a bug. http://stackoverflow.com/questions/7566755/multi-thread-o...

here is a patch for kernel 3.1:
http://marc.info/?l=linux-kernel&m=131822913806350&...

Another new ABI for fanotify

Blaisorblade — Sun, 20 Dec 2009 17:01:29 +0000

> There's not much overlap, but I wonder how you can implement a transaction containing one or more open() if these operations can block, call userspace and eventually abort.
Transactions have been invented in databases, and in that context it's obvious that part of a transaction may fail; and even in btrfs transactions allow for failures. So, what's the problem here?
A bigger problem is instead that during the transaction the filesystem is locked, so userspace needs to avoid modifying the fs during the check, if btrfs is used. It's possible I guess, the atime change problem needs to be solved to perform reads, but that's doable. But if developers don't test this scenario, they won't notice.

Another new ABI for fanotify

xav — Fri, 13 Nov 2009 10:13:27 +0000

There's not much overlap, but I wonder how you can implement a transaction containing one or more open() if these operations can block, call userspace and eventually abort.

Another new ABI for fanotify

bronson — Fri, 13 Nov 2009 02:46:37 +0000

> having a standard interface for viruses would greatly simplify their development.

That's an argument for keeping useful features out of the kernel? Are you kidding??

Pretty much all viruses are transferred via network. Does that mean that the networking stack should be removed from the kernel?

Another new ABI for fanotify

bronson — Fri, 13 Nov 2009 02:41:54 +0000

Why? Btrfs is dealing with bits on the platter, fanotify hooks in at the VFS. There's very little logical or conceptual overlap.

I really want ... something that is almost this...

knobunc — Fri, 13 Nov 2009 02:28:57 +0000

I have a large filesystem that I index. I couldn't care less about scanning things for malware, but this mechanism could help there...

Except, it looks like the interface does not generate events for file moves.

I know about the other notification mechanisms, but the tree is rather large and I do not want to have to add inotify_watches for all of the directories within... I assume (perhaps erroneously) that inotify does not scale to tens of thousands of directories.

-ben

Another new ABI for fanotify

xav — Thu, 12 Nov 2009 16:06:07 +0000

How fun ... here we have two consecutive articles, one dealing with making several file operations a transaction, the other trying to break down open() into two distinct operations (call userspace to check if I can open(), then open() for real).
I hardly see how both these approches can coexist ...

Another new ABI for fanotify

eparis — Thu, 12 Nov 2009 15:26:13 +0000

Clearly you don't understand the interface. I'm not going say anything other than "you are wrong" but if you do decide to do some research and find a real problem with my architecture please let me know and it will be addressed.

Another new ABI for fanotify

eparis — Thu, 12 Nov 2009 15:18:01 +0000

Pid is included in later patches.

Also you have an open fd which will not cause you to get events. So you can just operate on that fd and you won't hit the loop, open files yourself and you will get events for it.

Another new ABI for fanotify

etienne_lorrain@yahoo.fr — Thu, 12 Nov 2009 11:18:00 +0000

> The intended use case is malware-scanning utilities

Some would say the other intended use case is malware-spreading utilities, it is better to "infect" executables which are often executed than those who lay dormant... and having a standard interface for viruses would greatly simplify their development.
Moreover, because it seems you should be able to use multiple independant virus checker, you can hook "under" or "over" a virus checker, to hide your virus from upper layers, or to add it once the file has been certified clean.

Another new ABI for fanotify

mezcalero — Thu, 12 Nov 2009 03:57:28 +0000

I hope fanotify fixes one things that is really missing in the inotify API: some way to identify if some event was triggered by the process that is listening.

i.e. what inotify currently sucks at is to use it for reading files or devices nodes that have just been closed. i.e. a loop such as "for (;;) { wait_until_someone_closes_a_file_after_writing(); check_what_changed(); }", since the check_what_changed() call might itself open() and close() the file/device node, one would enter a loop here which is very hard to break, since one cannot distuingish between events that were triggered by the process itself or by someone else. An easy fix this could be to include the PID of the process that triggered an event. That way programs could simply ignore all events triggered by themselves.