Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755193AbYHRSLi (ORCPT ); Mon, 18 Aug 2008 14:11:38 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753427AbYHRSLa (ORCPT ); Mon, 18 Aug 2008 14:11:30 -0400 Received: from earthlight.etchedpixels.co.uk ([81.2.110.250]:58946 "EHLO lxorguk.ukuu.org.uk" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753266AbYHRSL3 (ORCPT ); Mon, 18 Aug 2008 14:11:29 -0400 Date: Mon, 18 Aug 2008 18:53:32 +0100 From: Alan Cox To: davecb@sun.com Cc: tvrtko.ursulin@sophos.com, Theodore Tso , Arjan van de Ven , Adrian Bunk , capibara@xs4all.nl, Casey Schaufler , david@lang.hm, linux-kernel , linux-security-module@vger.kernel.org, malware-list@lists.printk.net, malware-list-bounces@dmesg.printk.net, Mihai Don??u , Peter Dolding , Pavel Machek , rmeijer@xs4all.nl Subject: Re: [malware-list] scanner interface proposal was: [TALPA] Intro to a linux interface for on access scanning Message-ID: <20080818185332.202b32f0@lxorguk.ukuu.org.uk> In-Reply-To: <48A97C42.4040103@sun.com> References: <20080818142511.GC8184@mit.edu> <20080818153212.6A6FD33687F@pmx1.sophos.com> <20080818163148.0ef3e383@lxorguk.ukuu.org.uk> <48A97C42.4040103@sun.com> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; x86_64-redhat-linux-gnu) Organization: Red Hat UK Cyf., Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, Y Deyrnas Gyfunol. Cofrestrwyd yng Nghymru a Lloegr o'r rhif cofrestru 3798903 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: 1008 Lines: 22 > I suspect we're saying "on close" when what's really meant is > "opened for write". In the latter case, the notification would tell > the user-space program to watch for changes, possibly by something as > simple as doing a stat now and another when it gets around to Or more precisely perhaps "on the file becoming dirty". A program that opens for write, computes for an hour and writes out doesn't want to load events down until it begins writing. I agree "on close" is inaccurate for the scanner cases and that is why we've been talking about events + a close time event. > deciding if it should scan the file. I see lots of room for > user-space alternatives for change detection, depending on how much > state it keeps. Rsync-like, perhaps? 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/