Re: Fanotify events on the same file path

Re: Fanotify events on the same file path

[Amir Goldstein]

On Sun, Sep 4, 2022 at 4:26 PM Gal Rosen <gal.rosen@cybereason.com> wrote:
>
> Hi,
>
> I am using a single reader thread from an Fanotify file descriptor.
> The reader thread pushes file events into a queue.
> There are multiple worker threads which pop from the queue and do some actions on the file path (like file scanning for viruses).
> We have been told by the third party we are working with for the scanning API that we are scanning the same file path in parallel with 2 different objects.
> Is it possible to get multiple events on the same file path before response on the first event ?
>

Yes, there is nothing preventing that.
Multiple threads opening the same file will result in multiple
FAN_OPEN_PERM events, each with a different event->pid.

Thanks,
Amir.

Re: Fanotify events on the same file path

[Amir Goldstein]

On Sun, Sep 4, 2022 at 5:10 PM Gal Rosen <gal.rosen@cybereason.com> wrote:
>
> Hi Amir,
>
> And what about other events like FAN_CLOSE_WRITE ?

Permission events (e.g. FAN_OPEN_PERM) are never merged in the kernel queue.
FAN_CLOSE_WRITE is an async event, so it MAY be merged with other async
events (such as FAN_OPEN or another FAN_CLOSE_WRITE) on the same
path/object, but:
1. You have no guarantee that the kernel will merge events
2. Kernel will only merge events if all other info except the event mask
    is identical.

So for example, the file was opened by two different threads,
event->pid would be different so the two events would not be
merged.

>
> So, if I understand correctly, it is my responsibility to verify for multiplications
> of file events for the same file path before calling to scan. right ?
>

Right.
Since your application has a queue of its own, you are responsible to
do that anyway, because once you read a FAN_CLOSE_WRITE
event from the kernel and place it in the application queue, the
kernel will surely generate another FAN_CLOSE_WRITE event on
the next file close.

Thanks,
Amir.