RE: Is it possible to add pid and comm members to the event structure to increase the display of user and thread information?

[Nixiaoming <nixiaoming@huawei.com>]

on Thu, Sep 13, 2018 at 8:32 PM Amir Goldstein <amir73il@gmail.com>wrote:
>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.
>

Thank you for your guidance
I am modifying the code test locally,
The kernel mode selects whether to display the thread id information 
according to the FAN_EVENT_INFO_TID tag when fanotify_alloc_event is called 
the user mode test program adds FAN_EVENT_INFO_TID to the fanotify_markd parameter mask,  
now, it can accurately display which thread triggered the event.

I will send the patch later, please help me to review it

thanks