From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from helmsgmaster01.f-secure.com ([193.110.108.20]:55149 "EHLO helmsgmaster01.f-secure.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751297AbcJNI2M (ORCPT ); Fri, 14 Oct 2016 04:28:12 -0400 From: Marko Rauhamaa To: Amir Goldstein CC: linux-fsdevel Subject: Re: [RFC][PATCH 0/7] fanotify: add support for more events References: <87inswm9sg.fsf@drapion.f-secure.com> Date: Fri, 14 Oct 2016 11:28:07 +0300 In-Reply-To: (Amir Goldstein's message of "Thu, 13 Oct 2016 21:42:10 +0300") Message-ID: <87d1j3mj1k.fsf@drapion.f-secure.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Amir Goldstein : > On Thu, Oct 13, 2016 at 8:35 PM, Marko Rauhamaa >> My employer certainly is in need of monitoring a whole filesystem. We >> have noticed that namespaces evade monitoring via FAN_MARK_MOUNT. I >> was thinking something like a FAN_MARK_FILESYSTEM would be needed. > > [...] > > I keep hearing about people that wanted that feature, but those people will > need to come forward and voice their use cases. Well, F-Secure's Linux Security product monitors files to detect malware. Files are analyzed for viruses and unexpected modifications to system files are flagged. Other fanotify deficiencies include: * the offending process can die without leaving a trace because FAN_CLOSE_WRITE events do not block (instead of blocking, it would be enough for the /proc/$PID directory to stay available while the related fanotify fd is open) * the (e)uid and (e)gid of the offending process are not conveyed in the fanotify event * the FAN_OPEN_PERM event does not carry the mode so write access cannot be denied * there is no (PERM or non-PERM) event generated by the first modification (FAN_MODIFY generates a flurry of events; FAN_CLOSE_WRITE does not get generated unless the file is closed) Marko