SNOOP - A GNU/Linux file descriptor monitoring tool
INTRODUCTION
Snoop provides a mechanism for attaching to any open file descriptor and intercepting data. This can be useful in various scenarios (live user monitoring being probably the most common).
Inspired by FreeBSD's watch/snp, snoop goes beyond simple tty monitoring by allowing the interception of any type of file descriptor (currently limited to the standard namespace addressable entities though) on the fly: regular files, character devices, ttys, ptys, named FIFOs, etc.
Currently, snoop only works with recent 2.6 kernels and there's no plan for backporting it. Or course, the demand and supply laws apply ;)
BUILD & INSTALL
In order to support the kernel module build process you need the configured source tree of your target kernel. This is not a problem with modern distros or custom built kernels so hopefully you won't even notice. If you're building for a different kernel than what you're running, you can specify that at configuration time using "--with-kernel" and "--with-kernel-source" (try ./configure --help for more info).
The build & install procedure is straightforward:
./configure
make
su -c "make install"
If everything goes well you'll get a "snoop" utility in /usr{/local}/bin, and a module (snoop.ko) installed in /lib/modules/`uname -r`/misc/.
USAGE
Starting with 0.0.2, snoop creates the character device transparently, without relying on udev or bothering the user.
So, you can dive right in (root only, of course):
snoop [OPTIONS...] <FILE...>
For example, suppose you wanted to see what user jdoe is doing:
[root@alle ~]# who
mali :0 Jul 16 01:35 mali pts/1 Jul 16 01:36 (:0.0) mali pts/2 Jul 16 01:36 (:0.0) jdoe pts/3 Jul 16 11:45
[root@alle ~]# snoop /dev/pts/3
Attached to 1 FD(s).
CTRL-C to stop...
---
[jdoe@alle ~]$ muahaha, curiosity killed the cat...
That captures the write function on jdoe's terminal (what his apps are writing to /dev/pts/3) - this is the default behavior. Normally, the input is also echoed by the terminal so it shows up too. But there are some cases (password prompts for eg.) when that's not true. If you really want to see the input you should attach snoop on the 'read' function:
snoop -r /dev/pts/3
Now that only shows the user input but not the output from the apps. Not a problem, you can always attach on both functions (the gotcha here is that echoed input - and that's about 99% of it - shows up twice):
[root@alle ~]# snoop -r -w /dev/pts/3
Attached to 1 FD(s).
CTRL-C to stop...
---
[jdoe@alle ~]$ ppaasssswwdd
Changing password for user jdoe.
Changing password for jdoe
(current) UNIX password: hax0r
UNLOADING THE SNOOP MODULE
Once attached to some file descriptor(s), the module will stay busy until you exit the snoop utility AND the attached file descriptors are released. This means that in order to unload it, you have to wait until the snooped applications exit or close the file descriptor (for the not-so-patient there's always kill -9 ;).
If you want to snoop the real TTYs (/dev/tty?) I recommend attaching only after the user has logged in, as {min}getty does some funny stuff and manages to close the FD thus dropping snoop.
Comments, suggestions & bug reports are welcome.
Florin Malita <fmalita@gmail.com>