Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

[Marko Rauhamaa]

Filip ÅtÄdronskà <r.lkml@xxxxxxxxxx>:

> there are basically two classes of uses for a fantotify-like
> interface:
>
> (1) Keeping an up-to-date representation of the file system. For this,
>     superblock watches are clearly what you want.
>
>     [...]
>
>     All those factors speak greatly in favour of superblock
>     watches.
>
> (2) Tracking filesystem *activity*. Now you are not building
>     an image of current filesystem state but rather a log of what
>     happened. Perhaps you are also interested in who
>     (user/process/...) did what. Permission events also fit mostly in
>     this category.
>
>     For those it *might* make sense to have mount-scoped watches, for
>     example if you want to monitor only one container or a subset of
>     processes.
>
> We both concentrate on the first but we shouldn't forget about the
> second, which was one of the original motivations for fanotify.

My (employer's) needs are centered around (2). We definitely crave
permission events with a filesystem scope. At the moment, you can avoid
permission checks with a simple unshare command (<URL:
https://lkml.org/lkml/2016/12/21/144>).

So I must be able to see everything that is happening in my universe. It
might also be useful to monitor a subuniverse of mine, but the former
need is critical at the moment.

As for "who (user/process/...) did what", the fanotify API is flawed in
that we don't have a CLOSE_WRITE_PERM event. The hit-and-run process is
long gone by the time we receive the event. That's more of a rule than
an exception.


Marko