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

[Jan Kara]

On Wed 15-03-17 10:19:52, Marko Rauhamaa wrote:
> 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>).

Yes, that is bad.

> 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.

So I understand your need. However with superblock watches I'm still
concerned that the process would be able to see too much. E.g. if it is
restricted to see only some subtree of a filesystem (by bind mounts &
namespaces), it should not be able to see events on the same filesystem
outside of that subtree. I have not found a good solution for that yet.

> 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.

Adding CLOSE_WRITE_PERM would not be that difficult I assume. What do you
need it for?

								Honza
-- 
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR