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
