All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Bobrowski <repnop@google.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Jan Kara <jack@suse.cz>,
	Christian Brauner <christian.brauner@ubuntu.com>,
	Linux API <linux-api@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH 2/2] fanotify: Add pidfd support to the fanotify API
Date: Fri, 16 Apr 2021 18:08:16 +1000	[thread overview]
Message-ID: <YHlF8El4lcsHNYtR@google.com> (raw)
In-Reply-To: <CAOQ4uxjQi4dV0XoU2WDKG+3R81Xam6giee9hhkvXb13tQB+Tdg@mail.gmail.com>

On Fri, Apr 16, 2021 at 10:53:48AM +0300, Amir Goldstein wrote:
> On Fri, Apr 16, 2021 at 10:06 AM Matthew Bobrowski <repnop@google.com> wrote:
> > > > +               pidfd = pidfd_create(event->pid, 0);
> > > > +               if (unlikely(pidfd < 0))
> > > > +                       metadata.pid = FAN_NOPIDFD;
> > > > +               else
> > > > +                       metadata.pid = pidfd;
> > > > +       } else {
> > > > +               metadata.pid = pid_vnr(event->pid);
> > > > +       }
> > >
> > > You should rebase your work on:
> > > git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git fsnotify
> > > and resolve conflicts with "unprivileged listener" code.
> >
> > ACK.
> >
> > > Need to make sure that pidfd is not reported to an unprivileged
> > > listener even if group was initialized by a privileged process.
> > > This is a conscious conservative choice that we made for reporting
> > > pid info to unprivileged listener that can be revisited in the future.
> >
> > OK, I see. In that case, I guess I can add the FAN_REPORT_PIDFD check
> > above the current conditional [0]:
> >
> > ...
> > if (!capable(CAP_SYS_ADMIN) && task_tgid(current) != event->pid)
> >         metadata.pid = 0;
> > ...
> >
> > That way, AFAIK even if it is an unprivileged listener the pid info
> > will be overwritten as intended.
> >
> 
> Situation is a bit more subtle than that.
> If you override event->pid with zero and zero is interpreted as pidfd
> that would not be consistent with uapi documentation.

Ah, yes, of course! I had totally overlooked this. Also, speaking of
UAPI documentation, I'll have it prepared along with the LTP tests
once I get the ACK for this particular concept from Jan and Christian.

> You need to make sure that event->pid is FAN_NOPIDFD in case
> (!capable(CAP_SYS_ADMIN) &&
>  FAN_GROUP_FLAG(group, FAN_REPORT_PIDFD))
> Hopefully, you can do that while keeping the special cases to minimum...

I don't foresee any issues with doing this at all.

/M

  reply	other threads:[~2021-04-16  8:08 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-15 23:21 [PATCH 0/2] fanotify: Adding pidfd support to the fanotify API Matthew Bobrowski
2021-04-15 23:22 ` [PATCH 1/2] pidfd_create(): remove static qualifier and declare pidfd_create() in linux/pid.h Matthew Bobrowski
2021-04-19 10:13   ` Jan Kara
2021-04-19 12:50   ` Christian Brauner
2021-04-20  0:17     ` Matthew Bobrowski
2021-04-15 23:22 ` [PATCH 2/2] fanotify: Add pidfd support to the fanotify API Matthew Bobrowski
2021-04-16  6:27   ` Amir Goldstein
2021-04-16  7:05     ` Matthew Bobrowski
2021-04-16  7:53       ` Amir Goldstein
2021-04-16  8:08         ` Matthew Bobrowski [this message]
2021-04-19 13:02     ` Christian Brauner
2021-04-19 10:21   ` Jan Kara
2021-04-20  1:35     ` Matthew Bobrowski
2021-04-19 13:20   ` Christian Brauner
2021-04-19 13:53     ` Amir Goldstein
2021-04-19 14:44       ` Christian Brauner
2021-04-19 13:55     ` Jan Kara
2021-04-19 15:02       ` Christian Brauner
2021-04-20  2:36         ` Matthew Bobrowski
2021-04-21  8:04           ` Jan Kara
2021-04-21  9:29             ` Amir Goldstein
2021-04-21 10:00               ` Jan Kara
2021-04-21 10:12                 ` Amir Goldstein
2021-04-21 13:48                   ` Jan Kara
2021-04-21 14:46                     ` Christian Brauner
2021-04-22 23:06             ` Matthew Bobrowski
2021-04-23  7:39               ` Amir Goldstein
2021-04-23  8:02                 ` Matthew Bobrowski
2021-04-23  8:14                   ` Amir Goldstein
2021-04-26 10:26                     ` Matthew Bobrowski
2021-04-26 11:11                       ` Amir Goldstein
2021-04-27  3:35                         ` Matthew Bobrowski
2021-04-27  5:14                           ` Amir Goldstein
2021-04-28 22:53                             ` Matthew Bobrowski
2021-04-19 12:34 ` [PATCH 0/2] fanotify: Adding " Christian Brauner

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=YHlF8El4lcsHNYtR@google.com \
    --to=repnop@google.com \
    --cc=amir73il@gmail.com \
    --cc=christian.brauner@ubuntu.com \
    --cc=jack@suse.cz \
    --cc=linux-api@vger.kernel.org \
    --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.