3

I want to trap the below operations on a Linux system. Is it possible to do so efficiently? My end goal is to provide auditing and an additional set of filesystem metadata that is indexed differently. If the answer is "no", I appreciate pointers in a useful direction.


1) open(), and its parameters (where flags is O_CREAT)
2) write(), along with its parameters, *buf, and the struct file for fd, including f_pos
3) the corresponding information in 2 for a memory-mapped write to a file. I realize I'm asking something very difficult here as it requires an incestuous knowledge between the layers. Setting a flag that memory-mapped IO to a given open file has occurred is good enough, similar to how O_DIRECT writes might be handled. (triggering a later re-scan).
4) rename(), unlink()
5) mkdir(), rmdir()
6) truncate(), ftruncate()

If there are competing technologies to trap these kinds of operations, I am most interested in those that will last the longest (the most stability and community support), and those that are least filesystem-specific (the reiser4 plugins were exciting but don't seem politically viable).

Although my list 1-6 are simply examples, ideas as to what I've forgotten are helpful. But I'm not trying to be comprehensive, just communicate my design goal.

For example, passing this data to userspace would allow keeping a live locate/updatedb index. It would allow a database to track a per-block and per-file MD5. The availability of this data could facilitate snapshotting.

carlito
  • 2,489
  • 18
  • 12

5 Answers5

3

You want to use incrond. From the manpage:

   The inotify cron daemon (incrond) is a daemon which monitors filesystem
   events and executes commands defined in system and  user  tables.  It’s
   use is generally similar to cron(8).
Joe
  • 1,535
  • 1
  • 10
  • 15
1

Here are some related posts:

I'd consider the first to be a nice snapshotting solution if LVM or the upcoming NILFS2 aren't what you are looking for. Of course NILFS2 isn't tested extensively you'll have to decide for yourself if you take the risk and put that on a production server.

The second reference is more like security auditing but point roughly in the same direction.

Community
  • 1
Martin M.
  • 6,428
  • 2
  • 24
  • 42
  • Thanks. These two posts were in fact what inspired me to post my question - although it is something I had thought about for years, seeing that others desired the same thing, and that I had no solution besides creating an additional set of metadata, was inspirational. NILFS2 looks quite exciting and I think I can find people with similar goals working on that project. (In principle I want something filesystem-agnostic, but currently I need to find people with similar goals) – carlito Jun 10 '09 at 04:39
1

How about SystemTap? It is like Dtrace on Solaris. At least for system calls it seems to be a nice solution. It seems well supported on Fedora.

Allen
  • 1,315
  • 7
  • 12
1

Take a look at auditd. It should provide you with what you need.

zero_r
  • 2,345
  • 2
  • 15
  • 16
  • In previous excursions with auditd (perhaps RedHat Enterprise 4), I found that it exactly could not do this. Was I confused by reading RedHat configured and patched software with their default config (and possibly their docs)? I was very disappointed that autditd could not essentially audit my systems. (in that case the goal was log significant operations by any process, excluding any that risked filling the disk up or made the auditing system a bottleneck) – carlito Jun 14 '09 at 07:49
1

SeLinux combined with auditd is a way to get that data using methods that are already in the kernel.

Another option could be to use LD_PRELOAD tricks if you only want it for one application.

LapTop006
  • 6,466
  • 19
  • 26