Linux-Fsdevel Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Tycho Kirchner <tychokirchner@mail.de>,
	Matthew Bobrowski <mbobrowski@mbobrowski.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: fanotify feature request FAN_MARK_PID
Date: Fri, 28 Aug 2020 10:46:03 +0200	[thread overview]
Message-ID: <20200828084603.GA7072@quack2.suse.cz> (raw)
In-Reply-To: <CAOQ4uxiTCKrVBCjYrBsNWjRad+Tt_cONfD-nQCBr8x=TyLb_ww@mail.gmail.com>

On Sun 23-08-20 16:04:39, Amir Goldstein wrote:
> > Any further help is appreciated.
> >
> 
> A patch along those line (fill in the missing pieces) looks useful to me.
> It could serve a use case where applications are using fanotify filesystem
> mark, but developer would like to limit those application's scope inside
> "system containers".
> 
> Perhaps an even more useful API would be FAN_FILTER_MOUNT_NS.
> FAN_FILTER_PID_NS effectively means that kernel will drop events
> that are expected to report pid 0.
> FAN_FILTER_MOUNT_NS would mean that kernel will drop events that
> are expected to report an fd, whose /proc/<pid>/fd/<fd> symlink cannot
> be resolved (it shows "/") because the file's mount is outside the scope
> of the listener's mount namespace.
> 
> The burden of proof that this will be useful is still on you ;-)

I was thinking that we could add a BPF hook to fanotify_handle_event()
(similar to what's happening in packet filtering code) and you could attach
BPF programs to this hook to do filtering of events. That way we don't have
to introduce new group flags for various filtering options. The question is
whether eBPF is strong enough so that filters useful for fanotify users
could be implemented with it but this particular check seems implementable.

								Honza

> --- a/fs/notify/fanotify/fanotify.c
> +++ b/fs/notify/fanotify/fanotify.c
> @@ -685,6 +685,11 @@ static int fanotify_handle_event(struct
> fsnotify_group *group, u32 mask,
> 
>         pr_debug("%s: group=%p mask=%x\n", __func__, group, mask);
> 
> +       /* Interested only in events from group's pid ns */
> +       if (FAN_GROUP_FLAG(group, FAN_FILTER_PID_NS) &&
> +           !pid_nr_ns(task_pid(current), group->fanotify_data.pid_ns))
> +               return 0;
> +
>         if (fanotify_is_perm_event(mask)) {
>                 /*
>                  * fsnotify_prepare_user_wait() fails if we race with mark
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

      reply	other threads:[~2020-08-28  8:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-17 16:08 Tycho Kirchner
2020-08-17 17:02 ` Amir Goldstein
2020-08-22 22:47   ` Tycho Kirchner
2020-08-23 13:04     ` Amir Goldstein
2020-08-28  8:46       ` Jan Kara [this message]

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=20200828084603.GA7072@quack2.suse.cz \
    --to=jack@suse.cz \
    --cc=amir73il@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=mbobrowski@mbobrowski.org \
    --cc=tychokirchner@mail.de \
    --subject='Re: fanotify feature request FAN_MARK_PID' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).