Re: [PATCH 4.17] inotify: Add flag IN_ONLY_CREATE for inotify_add_watch()

[Amir Goldstein <amir73il@gmail.com>]

On Thu, May 3, 2018 at 6:24 PM, Henry Wilson <henry.wilson@acentic.com> wrote:
> From: Henry Wilson <henry.wilson@acentic.com>
>
> inotify: Add flag IN_ONLY_CREATE for inotify_add_watch()
>
> The flag IN_ONLY_CREATE is introduced as a flag for inotiy_add_watch() which
> prevents inotify from modifying any existing watches when invoked. If the
> pathname specified in the call has a watched inode associated with it and
> IN_ONLY_CREATE is specified, fail with an errno of EEXIST.
>
> Signed-off-by: Henry Wilson <henry.wilson@acentic.com>
> ---
> RATIONALE
>
> When using inotify_add_watch() a programmer will expect the watch descriptor to
> create a new watch descriptor referencing the inode the path is associated with.
> However while the word 'add' implies these semantics, the system call may either
> create or modify watches with this call. This would be fine if the interface has
> a mechanism by which to distinguish between these actions. If two files, file1,
> file2 the new path points to the same inode as an existing watch, for example
> with a hard-link, a dereferenced symbolic link or the original file being
> renamed. The programmer will be given a watch descriptor that they alrady have.
>
> IMPLICATIONS OF THE DEFECT
>
> The programmer may not realise the watch descriptor has been duplicated. Thus,
> two logical entities in the program will have the same watch descriptor and will
> compete for events from the queue. The watch descriptor will be deleted more
> times than neccessary in this case.
>
> The call to inotify_add_watch() may modify the watch mask for the original watch
> descriptor and the program may attempt to revert these changes. They may be
> unable to revert changes due to the path no-longer being associated with the
> same inode. The problem may be compounded if the path is assiciated with a
> different inode that is being watched. If IN_MASK_ADD was not used with the
> call, by the time the watch mask is reverted, important events may have been
> missed, without a mechanism to explicitly say that events were missed. (Unlike
> queue overflow)
>
> Thus it cannot currently be guaranteed that a watch descriptor will only
> generate events which have been requested. The program must filter events which
> come through its watch descriptor.
>
> ALTERNATIVES
>
> Create a new system call inotify_create_watch(fd, pathname, mask) which only
> creates watches. This would avoid creating a new flag-bit but would require some
> implementation refactoring. Adding a new flag-bit was chosen as currently 21
> IN_xxx flag-bits exist, an additional flag-bit leaves 10 remaining for future
> expansion. This leverages the existing implementation and as such is a minor
> implementation change.
>
> EXTENSIONS
>
> A new system call inotify_modify_watch(fd, wd, mask) would be useful to modify
> an existing watch directly to avoid similar problems when modifying a watch
> descriptor's mask
>
> ADDITIONS TO MANPAGES
>
> inotify(7)
>
>         IN_ONLY_CREATE
> Only watch pathname if it refers to an inode that is not already being watched
> by this inotify instance.
>
> inotify_add_watch(2)
>
>         EEXIST
> pathname references an existing watch descriptor and IN_ONLY_CREATE was
> specified.

I'm not crazy about the flag name. No great ideas for name. Maybe I_NO_UPDATE.

If this API change is considered, I would like to see a similar change
to fanotify,
because I don't like fact there is missing functionality in fanotify
and would not
like that gap to grow.

Thanks,
Amir.