From mboxrd@z Thu Jan  1 00:00:00 1970
From: Eric Paris <eparis-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Subject: Re: fanotify - overall design before I start sending
	patches
Date: Thu, 06 Aug 2009 14:18:10 -0400
Message-ID: <1249582690.20644.33.camel@dhcp231-106.rdu.redhat.com>
References: <1248466429.3567.82.camel@localhost>
	<200908061159.45550.tvrtko.ursulin@sophos.com>
	<1249557831.32113.234.camel@twins>
	<200908061348.43625.tvrtko.ursulin@sophos.com>
	<20090806135800.7ccb7787@lxorguk.ukuu.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: "david-gFPdbfVZQbY@public.gmane.org" <david-gFPdbfVZQbY@public.gmane.org>,
	"Valdis.Kletnieks-PjAqaU27lzQ@public.gmane.org" <Valdis.Kletnieks-PjAqaU27lzQ@public.gmane.org>,
	Peter Zijlstra <a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw@public.gmane.org>,
	Douglas Leeder <douglas.leeder-j34lQMj1tz/QT0dZR+AlfA@public.gmane.org>,
	"mrkafk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org" <mrkafk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	"aviro-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org" <aviro-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"malware-list-h+Im9A44IAFcMpApZELgcQ@public.gmane.org" <malware-list-h+Im9A44IAFcMpApZELgcQ@public.gmane.org>,
	"hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org" <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
	"alexl-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org" <alexl-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>, "jcm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org" <jcm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	"linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"jengelh-nopoi9nDyk+ELgA04lAiVw@public.gmane.org" <jengelh-nopoi9nDyk+ELgA04lAiVw@public.gmane.org>,
	"arjan-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org" <arjan-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
To: Alan Cox <alan-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org>
Return-path: <malware-list-bounces-h+Im9A44IAFcMpApZELgcQ@public.gmane.org>
In-Reply-To: <20090806135800.7ccb7787-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org>
List-Unsubscribe: <http://dmesg2.printk.net/cgi-bin/mailman/listinfo/malware-list>,
	<mailto:malware-list-request-h+Im9A44IAFcMpApZELgcQ@public.gmane.org?subject=unsubscribe>
List-Archive: <http://dmesg2.printk.net/pipermail/malware-list>
List-Post: <mailto:malware-list-h+Im9A44IAFcMpApZELgcQ@public.gmane.org>
List-Help: <mailto:malware-list-request-h+Im9A44IAFcMpApZELgcQ@public.gmane.org?subject=help>
List-Subscribe: <http://dmesg2.printk.net/cgi-bin/mailman/listinfo/malware-list>,
	<mailto:malware-list-request-h+Im9A44IAFcMpApZELgcQ@public.gmane.org?subject=subscribe>
Sender: malware-list-bounces-h+Im9A44IAFcMpApZELgcQ@public.gmane.org
Errors-To: malware-list-bounces-h+Im9A44IAFcMpApZELgcQ@public.gmane.org
List-Id: linux-fsdevel.vger.kernel.org

On Thu, 2009-08-06 at 13:58 +0100, Alan Cox wrote:
> > > We are taking about the kind of fanotify client that says: No you cannot
> > > open/read/write/mmap/etc.. this file until I say you can, right?
> > 
> > Yes and no, it would be more accurate to say "this open takes long while we do 
> > something else in the background".
> 
> There are two or three ways to handle this
> 
> 1.	Block the open until the daemon dies or responds
> 2.	Have a timeout (which would need to be connection configurable)
> 3.	Require the daemon responds with "in progress" now and then.

I've taken option #3.  I don't see options #2 as viable, although off
list discussion from clamav people has said they believe they are
interested in #2 rather than #3.

> For a superuser managed service its no different to an NFS mount which
> can go wonky so the only real question is what should fanotify allow non
> privileged users to do. The answer would appear anyway to be: not use
> this aspect of such a facility.

That's the approach taken thus far.  Although non-blocking/access
notification will be opened up to normal users (currently even
notification is root only)

> For the superuser case the fact the daemon can be killed thus releasing
> anything stuff is analogous to umount -f of a stuck NFS mount which seems
> perfectly good for NFS.

It does work for NFS (which I would call case #1.)  I claim that it
doesn't work for this case since a global listener stuck would stop you
from running kill() since it owuldn't be able to get permission to open
it....