Amir Goldstein <amir73il@xxxxxxxxx>:
> The main issue I have right now is with the ignore masks logic.
> The logic in send_to_group() doesn't match the logic in
> fanotify_should_send_event(), which in turn, does not match the man
> page documentation.
>
> I was thinking:
> - ignore mask on inode negates inode and mount and sb mark mask
> - ignore mask on mount negates mount and sb mark masks, but not inode
> mark mask
> - ignore mask on sb negates only sb mark mask
>
> The reasoning is that is makes sense to include a super set and
> exclude a subset. The problem is that inode is not really a subset of
> a mount, but mount and inode are really a subset of a super block.
>
> Current fanotify code seems to allow including an inode, but excluding
> a mount, which will result (I think) in getting events on the inode
> unless it was accessed from a specific mount. The examples of ignore
> mask in the fanotify(7) man page do not imply that this use case was
> intended and I really doubt if anybody is using ignore mask this way.
>
> I wonder if we should change the behavior of fanotify to only allow
> excluding an inode from a mount mark and not vice versa, as suggested
> by man page and by the logic in fsnotify() and send_to_group() and
> wait to see if anybody shouts.
>
> Thoughts?
First off, adjusting the semantics this way would not affect my
application code in any way.
However, ...
1. What you are proposing is going from include-then-exclude semantics
to big-to-small semantics. Big-to-small semantics are well defined
as long as two entities never partially overlap. That may well be
guaranteed in Linux file systems today, but I wonder if that
assumption can be cast in stone.
2. Include-then-exclude semantics is easy to state and understand. It
is also commonplace. Furthermore, I wonder if there was a real need
for reversed, exclude-then-include semantics. You can always set up
a second fanotify fd to monitor the exceptional includes.
3. This change potentially breaks some user-space applications out
there.
Marko
