From owner-freebsd-questions@FreeBSD.ORG Wed Oct 29 13:12:13 2003 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9CBCC16A4CF for ; Wed, 29 Oct 2003 13:12:13 -0800 (PST) Received: from mta7.adelphia.net (mta7.adelphia.net [68.168.78.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61AC343FBF for ; Wed, 29 Oct 2003 13:12:12 -0800 (PST) (envelope-from andi_payn@speedymail.org) Received: from [10.1.0.9] ([68.65.235.109]) by mta7.adelphia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20031029211215.MFBL29257.mta7.adelphia.net@[10.1.0.9]>; Wed, 29 Oct 2003 16:12:15 -0500 From: andi payn To: Matthew Seaman In-Reply-To: <20031029100015.GA21376@happy-idiot-talk.infracaninophile.co.uk> References: <000c01c39c3e$72c47950$fe01a8c0@JMICH> <20031027113545.GB11587@happy-idiot-talk.infracaninophile.co.uk> <1067418435.36829.690.camel@verdammt.falcotronic.net> <20031029100015.GA21376@happy-idiot-talk.infracaninophile.co.uk> Content-Type: text/plain Message-Id: <1067461899.36829.1519.camel@verdammt.falcotronic.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 29 Oct 2003 13:11:40 -0800 Content-Transfer-Encoding: 7bit cc: freebsd-questions@freebsd.org Subject: Re: Log every access to a file X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2003 21:12:13 -0000 On Wed, 2003-10-29 at 02:00, Matthew Seaman wrote: > On Wed, Oct 29, 2003 at 01:07:26AM -0800, andi payn wrote: > > > The second is to use fam. I should mention that I've only used fam under > > linux, and, after a brief glance, it looks like the FreeBSD port > > (/usr/ports/devel/fam) is not as powerful--in particular, FreeBSD > > apparently doesn't provide imon support (a way for the filesystem to > > make a callback to a usermode app like fam--no dnotify or anything > > similar, either, apparently). Which implies that it's probably just a > > heavier-weight way of doing the exact same thing--periodically stat'ing > > a list of files--and that there is no better solution available. > > Check the kevent(2) man page. It's a generic mechanism for having the > kernel message your process when some condition occurs, such as > modification of a file. Thanks. This is pretty cool, but it's missing a few things. First, it works only on UFS filesystems. That's no big deal; fam could use kevent on UFS and poll other filesystems. However, that does seem to rule it out for the original poster's purpose (the file he wanted to monitor was mounted via smb). More importantly, kevent apparently doesn't notify you when a file is accessed (or does changing the atime trigger NOTE_ATTRIB? in that case, it does--but to distinguish between an access and a change you'd have to stat the file). This seems to make it unusable for fam, as well as for the original poster's purpose (he wanted to see all accesses to a file). It also doesn't seem to notify you when a file in a directory you're watching is changed. This might would make fam much more complicated. However, I think the same is true of dnotify, so the extra code can probably be borrowed from the dnotify patch.... > Unfortunately other than knowing something > happened, it doesn't tell you a great deal else, like who it was that > made the alteration. Well, fam doesn't tell you anything more either; neither does imon nor dnotify--or stating a file directly. The OS and filesystem don't keep track of things like who was the last user or process to touch a file. If you want that, you could take fstat snapshots and hope to catch everyone who has the file open (this should work if users tend to access it for a long period of time, say a second or more). Or you could get a lease on a file and see who breaks it (although many programs might try to write the file without breaking your lock first, and just fail and give up--and besides, I don't know if that would work in FreeBSD the way it would in linux). Or you could put a fifo/socket/loopback filesystem/something between the actual file and the pathname people use to access it, and thereby control/monitor all access to it; etc. > Even so, fam(1) has apparently not been patched to use kevent(2) under > FreeBSD, so, yes, it's probably going to operate by polling the file > status every so often. Well, it looks like it would be a pretty easy patch to fam (especially since someone's already generalized the imon code to allow using dnotify instead), but if it can't provide information on accesses, it'd also be a useless patch (which might explain why nobody's done it yet?). Another issue: In linux, you can open a file O_NOACCESS (== O_ACCMODE, if you don't #include anything extra), which gets you an fd to pass to fstat/fcntl/whatever even without read or write access to the file. I assume the dnotify patch to fam uses this. This doesn't seem to work in FreeBSD. If you try to open a file O_ACCMODE, you get EACCES. Therefore, you'd have to open the file O_RDONLY to get an fd for kevent--which means you can't monitor a file that you can't read, which would be another limit placed on fam by using kevent. Plus, kevent doesn't seem to give you information on what's been changed within a directory, so fam would have to do some dirty work on each access (or monitor all files within the directory...). I think the same is true with dnotify; if so the kevent patch could use the same code as the dnotify patch, which is probably fine. Still, it's a good idea; I'll look into this a little deeper.