About:
Snoop is a GNU/Linux file descriptor monitoring tool inspired by FreeBSD's 'watch'. It goes beyond simple TTY snooping by allowing the interception of any file descriptor. You can attach on the fly to regular files, TTYs, named pipes, character devices, and pretty much anything that is represented by a file descriptor and addressable in the standard name space.

Author:
Florin Malita [contact developer]

Rating:	reset 1 2 3 4 5 6 7 8 9 10
(not rated)

Homepage:
http://snoop.sourceforge.net
Tar/GZ:
http://sourceforge.net/project/showfiles.php?group_id=143666
Changelog:
http://sourceforge.net/[..]es.php?group_id=143666&release_id=613243
CVS tree (cvsweb):
http://snoop.cvs.sourceforge.net/
Bug tracker:
http://sourceforge.net/tracker/?group_id=143666&atid=756163

Trove categories: [change]

[Development Status]		3 - Alpha, 4 - Beta
[Environment]		Console (Text Based)
[Intended Audience]		Advanced End Users, System Administrators
[License]		OSI Approved :: GNU General Public License (GPL)
[Operating System]		POSIX :: Linux
[Programming Language]		C
[Topic]		Security, System :: Logging, System :: Monitoring, System :: Systems Administration, Terminals, Utilities

Dependencies: [change]
No dependencies filed

 Branches

Branch	Version	Last release	License	URLs
Default	0.3.1	14-Jul-2008	GNU General Public License (GPL)

 Comments

[»] Snoop is badly chosen name
by Jörg Schilling - Jul 18th 2005 06:39:56

Snoop is the TCP/IP network sniffer on UNIX SVr4.

This is true since 1989, so you should rename your
program....

[reply] [top]

[»] Re: Snoop is badly chosen name
by Florin Malita - Jul 18th 2005 07:06:23

You do have a point but so is http://www.die.net/doc/linux/man/man1/watch.1.html vs http://www.bsdguides.org/guides/freebsd/misc/watch.php and a dozen other commands.

The "snoop" sniffer was never ported to Linux and I think the Linux package namespace is different enough from other UNIces to make this a non-issue. Heck, the availability of "snoop" on Freshmeat & SourceForge tells it all :)

Thanks for pointing it out though.

[reply] [top]

---

[»] Re: Snoop is badly chosen name
by Jan Engelhardt - Jul 21st 2008 19:49:23


> The "snoop" sniffer was never ported to Linux[...]
Probably because there are alternate solutions available, such as ttyrpld which, while relying on patching the source, does not change a filp's f_op (which can lead to surprising crashes just like trying to override syscalls). See http://ttyrpld.sourceforge.net/desc.php for details.

[reply] [top]

---

[»] Re: Snoop is badly chosen name
by Florin Malita - Jul 21st 2008 22:24:32


>
> > The "snoop" sniffer was never ported
> > to Linux[...]
>
> Probably because there are alternate
> solutions available, such as ttyrpld

This doesn't quite make sense: the discussion you're quoting was about name clashes with a network sniffer. A network sniffer (snoop from SVr4 according to Jorg) not being ported to linux has nothing to do with the availability of tty snoopers.

> which, while relying on patching the
> source, does not change a filp's f_op
> (which can lead to surprising crashes
> just like trying to override syscalls).
> See
> http://ttyrpld.sourceforge.net/desc.php
> for details.

Nice plug, but avoiding patching and rebuilding the kernel is quite a feature. How many kernel versions does ttyrpld support? I seriously doubt you generated rpldhk patches for more than a handful of kernels. What happens with the people using unsupported versions (or distro-patched kernels - which probably count for more than 90% of the installed base)? The patch based approach (besides being inconvenient) simply doesn't scale.

There's also a significant difference in scope: snoop is not just a tty logger but a generic fd monitoring tool. You can attach to any open file descriptor - sockets, files, pipes - you name it. If you can find it in /proc/<pid>/fd/, you can attach to it and take a peek at what's going on in a non intrusive way.

As far as stability is concerned, I have yet to see or hear of crashes caused by the snoop module. The tty layer plays tricks with fipl->f_op too, so that in itself is not fundamentally broken. If you can spot any races please file a bug report, but as far as I can tell the f_op updates are performed in a safe manner.

[reply] [top]

---