From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Marko Rauhamaa To: Filip =?utf-8?B?xaB0xJtkcm9uc2vDvQ==?= CC: Amir Goldstein , linux-fsdevel , linux-kernel , Jan Kara , Alexander Viro Subject: Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes References: <20170314145801.qbiybrfpnaff2xmc@rgvaio> Date: Wed, 15 Mar 2017 10:19:52 +0200 In-Reply-To: <20170314145801.qbiybrfpnaff2xmc@rgvaio> ("Filip \=\?utf-8\?B\?xaB0xJtkcm9uc2vDvSIncw\=\=\?\= message of "Tue, 14 Mar 2017 15:58:01 +0100") Message-ID: <871stzc5p3.fsf@drapion.f-secure.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: Filip Štědronský : > 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 (). 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