Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753274AbZIPKqv (ORCPT ); Wed, 16 Sep 2009 06:46:51 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751935AbZIPKqv (ORCPT ); Wed, 16 Sep 2009 06:46:51 -0400 Received: from mga06.intel.com ([134.134.136.21]:43639 "EHLO orsmga101.jf.intel.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751847AbZIPKqu (ORCPT ); Wed, 16 Sep 2009 06:46:50 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.44,397,1249282800"; d="scan'208";a="448975004" Date: Wed, 16 Sep 2009 11:41:11 +0100 From: Alan Cox To: Jamie Lokier Cc: Eric Paris , Linus Torvalds , Evgeniy Polyakov , David Miller , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, netdev@vger.kernel.org, viro@zeniv.linux.org.uk, hch@infradead.org Subject: Re: fanotify as syscalls Message-ID: <20090916114111.2228f0fc@linux.intel.com> In-Reply-To: <20090916075219.GA22024@shareable.org> References: <20090911212731.GA19901@shareable.org> <1252705902.2305.83.camel@dhcp231-106.rdu.redhat.com> <20090912094110.GB24709@ioremap.net> <20090914001759.GB30621@shareable.org> <20090914140720.GA8564@ioremap.net> <1252955295.2246.35.camel@dhcp231-106.rdu.redhat.com> <20090915201620.GB32192@ioremap.net> <1253051699.5213.18.camel@dhcp231-106.rdu.redhat.com> <1253064391.5213.37.camel@dhcp231-106.rdu.redhat.com> <20090916075219.GA22024@shareable.org> Organization: Intel X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.5; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1649 Lines: 38 > - fanotify does not provide subtree notification in it's > present form. When it is extended to do that, why wouldn't > inotify be as well? That's an fsnotify feature, common to both. Because inotify gives you no reliable access to the object monitored as the name passed back is not an object reference and is racy. Inotify is fine for making pretty icons pop up on desktops and making file selectors update, but it is somewhat inadequate for indexers and completely useless for stuff like HSM. > - fanotify requires you call readlink(/proc/fd/N) for every event to > get the path. It's not a particularly efficient way to get it, IFF you want the path, but the path isn't usually the most valuable bit. Plus you'll find the readlink is extremely quick anyway. > People who want to break out of chroot/namespace jails using the > conveniently provided open file descriptor? :-) chroot isn't a security model. You can already do this with AF_UNIX sockets (and there are apps that intentionally use fchdir that way) > I'd expect anti-malware to want to be run inside VMs quite often... Inside of containers - unlikely. Inside of guests sure but thats not going to relevant to fanotify() > the accessing process until acked), that's ok with me. It makes > sense. But then it's messy that neither offers a superset of the > other regarding which files and events are tracked. Agreed. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/