Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <E490CD805F7529488761C40FD9D26EF12A7A1814@dggemm507-mbs.china.huawei.com>
 <CAOQ4uxiQ_Kb9H9z5nCJL0XJGO_2Dn2Z3KtGv2WZHkt-e+vkZ=w@mail.gmail.com> <E490CD805F7529488761C40FD9D26EF12A7A5ADA@dggemm507-mbs.china.huawei.com>
In-Reply-To: <E490CD805F7529488761C40FD9D26EF12A7A5ADA@dggemm507-mbs.china.huawei.com>
From:   Amir Goldstein <amir73il@gmail.com>
Date:   Thu, 13 Sep 2018 15:31:42 +0300
Message-ID: <CAOQ4uxjQK_PKAp2WMPewPZzVhE9WGHfuxyQBPcjyJ6xdJ_j7Dw@mail.gmail.com>
Subject: Re: Is it possible to add pid and comm members to the event structure
 to increase the display of user and thread information?
To:     nixiaoming@huawei.com
Cc:     Eric Paris <eparis@parisplace.org>, Robert Love <rlove@rlove.org>,
        John McCutchan <john@johnmccutchan.com>,
        Jan Kara <jack@suse.cz>, Al Viro <viro@zeniv.linux.org.uk>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Sep 13, 2018 at 2:25 PM Nixiaoming <nixiaoming@huawei.com> wrote:
>
> On Tue, Sep 11, 2018 at 11:12 PM Amir Goldstein <amir73il@gmail.com> wrote:
> >On Tue, Sep 11, 2018 at 9:51 AM Nixiaoming <nixiaoming@huawei.com> wrote:
> >>
> >> Inotify api cannot display information about users and processes.
> >> That is, you can only know that the file event is generated, but you don't know who triggered the event, which is not conducive to fault location.
> >> Is it possible to add pid and comm members to the event structure to increase the display of user and thread information?
> >>
> >
> >"Is it possible?" is not the only relevant question.
> >I suppose your patch can sort of works, but it exposes information to
> >potentially unpriveleged
> >processes, even exposes pid values outside of the process pid namespace.
> >
> >While those issues could be addressed, you can't change the format
> >struct inotify_event
> >without breaking existing applications.
> >
> In order to improve the fault location capability, can we make incompatible interface changes?

Not unless application/sysadmin/distro opts-in for the incompatible change.

>
> >I guess you are not using fanotify API, which already provides pid
> >information (albiet tgid),
> >because it lacks other functionality that you need? Which
> >functionality might that be?
> >Is it directory modification events?
> >If so than you might be interested in my effort to add support for
> >those events to fanotify:
> >https://github.com/amir73il/fsnotify-utils/wiki/Super-block-root-watch
> >
> The fanotify API does not support monitoring file deletion events

Yes, I am working toward that goal.

> The fanotify API supports tgid display,
> but for multi-threaded programs,
> it still cannot accurately identify which thread triggered the event.
> Can I modify tgid to pid?
> - event->tgid = get_pid(task_tgid(current));
> + event->tgid = get_pid(task_pid(current));
>

So if you would like to change that you need to add a new flag to
fanotify_init (e.g. FAN_EVENT_INFO_TID)
new applications that would opt-in for the flag will get task_pid()
while existing application will keep getting task_tgid()
new applications will get -EINVAL when passing FAN_EVENT_INFO_TID
to fanotify_init() on an old kernel and they could then fall back to getting
tgid in events and be aware of that fact.

Thanks,
Amir.