Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753624AbdCONkJ (ORCPT ); Wed, 15 Mar 2017 09:40:09 -0400 Received: from mx2.suse.de ([195.135.220.15]:49384 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751147AbdCONj5 (ORCPT ); Wed, 15 Mar 2017 09:39:57 -0400 Date: Wed, 15 Mar 2017 14:39:52 +0100 From: Jan Kara To: Marko Rauhamaa Cc: Filip =?utf-8?B?xaB0xJtkcm9uc2vDvQ==?= , Amir Goldstein , linux-fsdevel , linux-kernel , Jan Kara , Alexander Viro Subject: Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes Message-ID: <20170315133952.GH12989@quack2.suse.cz> References: <20170314145801.qbiybrfpnaff2xmc@rgvaio> <871stzc5p3.fsf@drapion.f-secure.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <871stzc5p3.fsf@drapion.f-secure.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2202 Lines: 56 On Wed 15-03-17 10:19:52, Marko Rauhamaa wrote: > 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 ( 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 SUSE Labs, CR