On Sat, Jun 5, 2021 at 7:04 PM J. R. Okajima <hooanon05g@xxxxxxxxx> 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.
