On Tue, Sep 15, 2020 at 10:08 AM Jan Kara <jack@xxxxxxx> wrote: > > On Tue 15-09-20 01:27:43, Weiping Zhang wrote: > > Now the IN_OPEN event can report all open events for a file, but it can > > not distinguish if the file was opened for execute or read/write. > > This patch add a new event IN_OPEN_EXEC to support that. If user only > > want to monitor a file was opened for execute, they can pass a more > > precise event IN_OPEN_EXEC to inotify_add_watch. > > > > Signed-off-by: Weiping Zhang <zhangweiping@xxxxxxxxxxxxxx> > > Thanks for the patch but what I'm missing is a justification for it. Is > there any application that cannot use fanotify that needs to distinguish > IN_OPEN and IN_OPEN_EXEC? The OPEN_EXEC notification is for rather > specialized purposes (e.g. audit) which are generally priviledged and need > to use fanotify anyway so I don't see this as an interesting feature for > inotify... That would be my queue to re- bring up FAN_UNPRIVILEGED [1]. Last time this was discussed [2], FAN_UNPRIVILEGED did not have feature parity with inotify, but now it mostly does, short of (AFAIK): 1. Rename cookie (*) 2. System tunables for limits The question is - should I pursue it? You asked about incentive to use feature parity fanotify and not intotify. One answer is the ignored mask. It may be a useful feature to some. But mostly, using the same interface for both priv and unpriv is convenient for developers and it is convenient for kernel maintainers. I'd like to be able to make the statement that inotify code is maintained in bug fixes only mode, which has mostly been the reality for a long time. But in order to be able to say "no reason to add IN_OPEN_EXEC", we do need to stand behind the feature parity with intotify. So I apologize to Weiping for hijacking his thread, but I think we should get our plans declared before deciding on IN_OPEN_EXEC, because whether there is a valid use case for non-priv user who needs IN_OPEN_EXEC event is not the main issue IMO. Even if there isn't, we need an answer for the next proposed inotify feature that does have a non-priv user use case. Thanks, Amir. [1] https://github.com/amir73il/linux/commits/fanotify_unpriv [2] https://lore.kernel.org/linux-fsdevel/20181114135744.GB20704@xxxxxxxxxxxxxx/ (*) I got an internal complaint about missing the rename cookie with FAN_REPORT_NAME, so I had to carry a small patch internally. The problem is not that the rename cookie is really needed, but that without the rename cookie, events can be re-ordered across renames and that can generate some non-deterministic event sequences. So I am thinking of keeping the rename cookie in the kernel event just for no-merge indication and then userspace can use object fid to match MOVED_FROM/MOVED_TO events.
