[ale] file modification time via shell script

[Jim Popovitch]

On Fri, 2007-08-03 at 16:07 -0400, Daniel Kahn Gillmor wrote:
> this is basically the right approach (i haven't checked syntax either,
> and as usual, it will have difficulty with filenames with spaces in
> them), but it has a couple flaws.
> 
> First, the modification time could be reset to evade detection, if
> that matters to you.
> 
> And also, it suffers from a race condition, especially if the find
> operation itself takes a long time to complete.  That is, a file
> modified during the find run (but after find has examined it) won't
> ever show up: it fails to show during the run because it hasn't been
> changed yet when find looks at it, and it won't show up on the
> following run because the flag's timestamp is after the change.
> 
> touching a separate flag file before the find and then moving it into
> the canonical flagfile location is only slightly better: its race
> condition is the other way around, and can trigger twice based on only
> a single change.
> 
> what about an approach which stores the full state of the directories
> it cares about and highlights the differences?
> 
>   http://aplawrence.com/Unixart/watchdir.html
> 
> More generally, this problem is an intrusion-detection problem that
> might be handled by tools like fcheck or tripwire.  Since i don't know
> what you want to do with the information about the changes, i'm not
> sure how useful those generic IDS tools would be.  But you might want
> to look at their implementations if you want a robust strategy.
> 
>  http://sourceforge.net/projects/tripwire/
>  http://packages.debian.org/unstable/admin/fcheck

:-) Wow. Thanks.  Greg's approach will work just fine, I'm only trying
to determine when a single log file is updated so that i can kick off a
process.  The cron runs every minute so if someone else touches the
state file then the cron will pick it up next cycle.  I did add a lock
file so that it can't run if it's still running.

Thanks,

-Jim P.