fanotify: FAN_OPEN_EXEC_PERM stops invoking the commands

fanotify: FAN_OPEN_EXEC_PERM stops invoking the commands

[J. R. Okajima]

Hello,

fanotify has a neat feature called "perm event" which makes the listener
process can allow/deny the access to a file by another process.
But it doesn't work well if
- FAN_OPEN_EXEC_PERM event is monitored
- the other process's executable is monitored by the listener process

The scenario is like this.
- fanotify_init(O_RDWR)
- fanotify_mark(FAN_OPEN_EXEC_PERM, "/dirA")
- read() the event via fanotify_fd. it blocks.
and run "/dirA/a.out" executable on another terminal.

Then
- FAN_OPEN_EXEC_PERM event is enqueued
- the listener process tries reading the event
- fanotify tries preparing FD by opening the executable. the flag to
  open is the one given to fanotify_init(). it is O_RDWR here.
- we cannot open the running executable with O_RDWR flag.
- fanotify forces FAN_DENY as a response to the perm event.
- the listener read() gets ETXTBSY from fanotify.

As a result,
- the listener process cannot get the perm event, and cannot write
  the response FAN_ALLOW either.
- a.out process fails to start (EPERM) because fanotify sets FAN_DENY.

In other words, fanotify stops invoking a.out even if the listener
process wants to allow it.
That is bad.

My question is,
Why do we need to reuse full fsnotify_group->fanotify_data.f_flags when
opening the executable?  I can understand people may want to set
O_NONBLOCK or O_CLOEXEC flags.  But how about RW flags?  Isn't it good
enough to force opening fanotify_event_metadata.fd with O_RDONLY?
Passing O_RDWR to fanotify_init() should be kept in order to make
fanotify_fd writable.


J. R. Okajima

Re: fanotify: FAN_OPEN_EXEC_PERM stops invoking the commands

[Amir Goldstein]

On Sat, Jun 5, 2021 at 7:04 PM J. R. Okajima <hooanon05g@gmail.com> wrote:
>
> Hello,
>
> fanotify has a neat feature called "perm event" which makes the listener
> process can allow/deny the access to a file by another process.
> But it doesn't work well if
> - FAN_OPEN_EXEC_PERM event is monitored
> - the other process's executable is monitored by the listener process
>
> The scenario is like this.
> - fanotify_init(O_RDWR)

Did you mean:
- fanotify_init(FAN_CLASS_CONTENT, O_RDWR) ?
I think you want:
- fanotify_init(FAN_CLASS_CONTENT, O_RDONLY)

> - fanotify_mark(FAN_OPEN_EXEC_PERM, "/dirA")
> - read() the event via fanotify_fd. it blocks.
> and run "/dirA/a.out" executable on another terminal.
>
> Then
> - FAN_OPEN_EXEC_PERM event is enqueued
> - the listener process tries reading the event
> - fanotify tries preparing FD by opening the executable. the flag to
>   open is the one given to fanotify_init(). it is O_RDWR here.
> - we cannot open the running executable with O_RDWR flag.
> - fanotify forces FAN_DENY as a response to the perm event.
> - the listener read() gets ETXTBSY from fanotify.
>
> As a result,
> - the listener process cannot get the perm event, and cannot write
>   the response FAN_ALLOW either.
> - a.out process fails to start (EPERM) because fanotify sets FAN_DENY.
>
> In other words, fanotify stops invoking a.out even if the listener
> process wants to allow it.
> That is bad.
>
> My question is,
> Why do we need to reuse full fsnotify_group->fanotify_data.f_flags when
> opening the executable?  I can understand people may want to set
> O_NONBLOCK or O_CLOEXEC flags.  But how about RW flags?  Isn't it good
> enough to force opening fanotify_event_metadata.fd with O_RDONLY?
> Passing O_RDWR to fanotify_init() should be kept in order to make
> fanotify_fd writable.
>

fanotify_fd is writable regardless of the argument event_f_flags of
fanotify_init(). See fanotify_init(2) man page and example in fanotify(7).

Thanks,
Amir.

Re: fanotify: FAN_OPEN_EXEC_PERM stops invoking the commands

[hooanon05g]

Amir Goldstein:
> fanotify_fd is writable regardless of the argument event_f_flags of
> fanotify_init(). See fanotify_init(2) man page and example in fanotify(7).

Ah, I was misunderstanding the meaning of event_f_flags.
Thanks for clarifying.


J. R. Okajima