From: Marko Rauhamaa <marko.rauhamaa@f-secure.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Jan Kara <jack@suse.cz>, linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: fanotify super block mark and ignore mask
Date: Wed, 4 Apr 2018 10:48:15 +0300 [thread overview]
Message-ID: <87a7ujza2o.fsf@drapion.f-secure.com> (raw)
In-Reply-To: <CAOQ4uxgmJ=5e5-Ap3=xuXLeZhdGK762F6rf4jsEvs6oOSfrtEw@mail.gmail.com> (Amir Goldstein's message of "Tue, 3 Apr 2018 22:49:05 +0300")
Amir Goldstein <amir73il@gmail.com>:
> 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
next prev parent reply other threads:[~2018-04-04 8:06 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-03 19:49 fanotify super block mark and ignore mask Amir Goldstein
2018-04-04 7:48 ` Marko Rauhamaa [this message]
2018-04-04 8:31 ` Amir Goldstein
2018-04-04 9:06 ` Marko Rauhamaa
2018-04-04 11:55 ` Jan Kara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a7ujza2o.fsf@drapion.f-secure.com \
--to=marko.rauhamaa@f-secure.com \
--cc=amir73il@gmail.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.