All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.