Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752304AbdCOIqi convert rfc822-to-8bit (ORCPT ); Wed, 15 Mar 2017 04:46:38 -0400 Received: from helmsgagent01.f-secure.com ([193.110.108.21]:55604 "EHLO helmsgagent01.f-secure.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751941AbdCOIqg (ORCPT ); Wed, 15 Mar 2017 04:46:36 -0400 X-Greylist: delayed 1596 seconds by postgrey-1.27 at vger.kernel.org; Wed, 15 Mar 2017 04:46:35 EDT 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> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1567 Lines: 42 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