Re: [RFC][PATCH 0/7] fanotify: add support for more events

[Jan Kara <jack@suse.cz>]

Hi,

On Mon 10-10-16 22:12:57, Amir Goldstein wrote:
> This series is a prep work for using fanotify to monitor all
> events in a file system with a single watch.
> 
> The end result is indented to be an alternative to the recursive
> inotify watches scheme, which has its problems.
> 
> This first part adds support for most inotify events to fanotify
> when watching a directory.

Well, and how is this better than what inotify supports? The proclaimed
advantage of fanotify() was that you get open file handle in the event
which prevents races when directory tree changes before you manage to
process inotify event. However with directory changes, you are again
starting to report names and so things become racy again. So I don't quite
see a value of reimplementing this in fanotify. The only benefit I see is
that you can watch the whole mountpoint with one watch instead of having to
add watch to every directory. Is that such a huge win? What is a use case
for that?

> The next part will add support for watching a super block,
> which is not the same as watching a mount point.

Careful here. In the world of user namespaces and containers you have to be
really careful so that events from one container don't leak into another
container despite they live in the same physical filesystem, just a
different bind mount. I believe chroot / bind mounts was one of the reasons
why fanotify ended with mountpoints and not with superblocks. But I guess
Eric or Al remember this better.

> I am posting this WIP to get feedback on the idea and to find
> out if there are any users out there interested in the improved
> fanotify capabilities and/or in the super block monitoring
> use case.

Well, I hope you have some usecases in mind when you propose this ;) I've
been asked about fanotify for superblocks but so far I think that doing it
in kernel would be a headache (mostly security-wise) and doing it in
userspace - watch every mountpoint in /proc/mounts - may be less
error-prone.

								Honza

> 
> Amir Goldstein (7):
>   fsnotify: pass dentry instead of inode when available
>   fsnotify: annotate filename events
>   fanotify: new init flag FAN_EVENT_INFO_PARENT
>   fanotify: store mount point from which an inode watch was added
>   fanotify: support events with data type FSNOTIFY_EVENT_DENTRY
>   fanotify: add support for create/attrib/rename/delete events
>   fanotify: pass filename info for filename events
> 
>  fs/notify/fanotify/fanotify.c      | 85 +++++++++++++++++++++++++++++++----
>  fs/notify/fanotify/fanotify.h      | 24 +++++++++-
>  fs/notify/fanotify/fanotify_user.c | 92 ++++++++++++++++++++++++++++++++++----
>  fs/notify/fdinfo.c                 |  4 +-
>  fs/notify/fsnotify.c               |  2 +-
>  fs/notify/inode_mark.c             |  1 +
>  fs/notify/mark.c                   | 15 +++++--
>  include/linux/fsnotify.h           | 46 ++++++++++++++-----
>  include/linux/fsnotify_backend.h   | 24 +++++++---
>  include/uapi/linux/fanotify.h      | 41 ++++++++++++++---
>  10 files changed, 287 insertions(+), 47 deletions(-)
> 
> -- 
> 2.7.4
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR