Tree [49d8e5] master /
History



File Date Author Commit
autoconf 2005-07-17 mali mali [b5ec88] Initial revision
kernel 2011-02-19 Florin Malita Florin Malita [0fbbdd] * avoid using init_MUTEX (removed in 2.6.37)
man 2006-02-20 mali mali [b85412] * man update
src 2007-04-26 mali mali [08967f] * fixed fragile system() invokation - used to b...
AUTHORS 2005-07-17 mali mali [b5ec88] Initial revision
COPYING 2005-07-17 mali mali [b5ec88] Initial revision
ChangeLog 2011-02-19 Florin Malita Florin Malita [49d8e5] * preparing for 0.3.2
INSTALL 2005-07-17 mali mali [b5ec88] Initial revision
Makefile.am 2006-02-21 mali mali [b822cb] * added .spec file
NEWS 2006-10-03 mali mali [8683a7] * commit test
README 2005-11-02 mali mali [c073e1] * documentation update
autogen.sh 2005-07-17 mali mali [b5ec88] Initial revision
configure.in 2011-02-19 Florin Malita Florin Malita [49d8e5] * preparing for 0.3.2
snoop.spec.in 2006-02-21 mali mali [b822cb] * added .spec file

Read Me

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>