Forgot your password?
typodupeerror
OS X Businesses Operating Systems Apple

Watching Under The Hood Of Tiger's Spotlight 43

Posted by Hemos
from the looking-at-it dept.
jaketheitguy writes "Over at KernelThread.com, Amit Singh has released a commandline app called FSLogger for looking under the hood of Tiger's Spotlight. You can watch all kinds of filesystem changes going on in realtime. The utility apparently intercepts and displays filesystem change data as it goes out to Spotlight from the kernel. It even tells you which app is making the changes. Looks like Apple has included some pretty powerful API's in Tiger and there may be some othre really interesting uses of this API as mentioned on the app's page. I for one would really like to be able to tell if somebody changed ANY files on my system without my knowledge. I think you can do that with Singh's program, but how do you make sure somebody cannot disable the program?"
This discussion has been archived. No new comments can be posted.

Watching Under The Hood Of Tiger's Spotlight

Comments Filter:
  • by Anonymous Coward on Monday May 23, 2005 @09:18AM (#12611189)
    First there always has been a program called /usr/bin/fs_usage which monitors file system access. Second is the story writer worried about someone altering his files or about spotlight. How spotlight functions has been the subject of many detailed articles. Any time you change a file, spotlight calls the appropriate indexing program and collects and stores the metadata. It is not going to alter the data fork of your document but the data has to get stored somewhere. So relax. this story is paranoid delusional.
  • Tripwire (Score:3, Informative)

    by @madeus (24818) <slashdot_24818@mac.com> on Monday May 23, 2005 @10:12AM (#12611633)
    Actually you can get this functionality already in a long standing Unix utility called Tripwire.

    http://www.tripwire.com/ [tripwire.com]
    http://sourceforge.net/projects/tripwire/ [sourceforge.net]

    There is even a Mac OS X version now it seems:
    http://www.macguru.net/~frodo/Tripwire-osx.html [macguru.net]

    Of course you'd probably then want an OS that implements some form of relevant Mandatory Access Control / POSIX.1e (e.g. LIDS for Linux, Trusted Solaris, or Argus Pitbull (Linux/Solaris)) to help prevent the intruder from interfering with Tripwire itself.
  • by As Seen On TV (857673) <asseen@gmail.com> on Monday May 23, 2005 @11:53AM (#12612606)
    No, I'm just out of the office this week.
  • by Simon Spero (10945) on Monday May 23, 2005 @12:03PM (#12612701)
    There's a system call that lets user-space programs subscribe to a lot of interesting kernel level events.

    Take a look at the kqueue(2) man page.

    There are more details available at http://people.freebsd.org/~jlemon/papers/kqueue.pd f [freebsd.org]

  • Tripwire (Score:2, Informative)

    by mithran8 (186371) on Monday May 23, 2005 @03:01PM (#12615505) Homepage
    You may be shocked to know how often files change on your system... without a good policy defining the scope of your monitoring, you're asking for a world of hurt. As @madeus mentions, there is an OS X build of Tripwire which gives you a good deal of this functionality. Two caveats, however:

    - Tripwire is not a real-time service, it's scheduled to run at specific (user-defined) times.

    - Tripwire does not prevent anyone from making changes - it merely ensures that any changes to the OS are recorded and made visible to you.

    That said, Tripwire is a very functional tool with excellent scripting and integration potential. Plus, it has a good amount of internal security - unless you know the relevant passphrases, you cannot subvert the product. If you root the box you can always uninstall it, but you can't tamper with the database or policy to hide your changes or trick Tripwire into sending a false 'all clear' message.

    As with all such tools, it's best to check it out and evaluate it for yourself to see how it works for you.
  • Re:Tripwire (Score:3, Informative)

    by womby (30405) on Tuesday May 24, 2005 @03:28AM (#12621218)
    I am going to assume you didn't read the article and provide a small description of what fslogger is doing and how it has nothing in common with tripwire.

    Fslogger runs continuously and registers itself with the kernel, when a filesystem change event happens details about it are announced to all registered apps and fslogger displays the information it receives in a useful (if verbose) manner.

    Tripwire is a fantastically useful app which I run on every one of the servers I admin, and perhaps the OSX version could be extended to make use of the same kernel interfaces that fslogger is using.

    Tripwire runs once per day (however often you wish to run it), and scans the filesystem checking each file to see if it matches a checksum calculated at some known time in the past. This is useful on mission critical servers because outside of data / user directories changes should happen very infrequently. Tripwire is a robust way of confirming that a server has the same configuration on a day to day basis.

    The startling difference between tripwire and fslogger should be obvious, tripwire has no mechinism to know when a file has changed except by looking at the file directly, fslogger has no mechinism to know if the event is important or not and no mechinism to notify an administrator of the event short of scrolling it by in a terminal.

    With tripwire you could delete a file, recreate it from backup and so long as you was careful tripwire would never know. fslogger would display every step you took but would not know if the final step returned the filesystem to its original state.

    Different tools with different behaviours for different target users presenting different information in a different manner.

    So, to dispute your original assertation,
    "Actually you can get this functionality already in a long standing Unix utility called Tripwire."
    No, nothing fslogger does is replicated by tripwire and nothing tripwire does is replicated by fslogger.

"Consequences, Schmonsequences, as long as I'm rich." -- "Ali Baba Bunny" [1957, Chuck Jones]

Working...