* Snooping on sockets/file descriptors [not found] <AANLkTimuc_tuZ9kVJU6q6CXDzE737vZYvfrKekN+SzcM@mail.gmail.com> @ 2011-03-31 19:29 ` Vimal 2011-03-31 19:58 ` Daniel Baluta 2011-04-04 15:43 ` Florin Malita 0 siblings, 2 replies; 8+ messages in thread From: Vimal @ 2011-03-31 19:29 UTC (permalink / raw) To: kernelnewbies Hi, Is it possible for an application (say "snoop", with sufficient privileges) to monitor data on any socket/file descriptor in the system? Here's an example: ?suppose we have a browser and it creates a tcp socket to connect to a URL. ?Whenever the browser issues a read() and data is pushed to user space, I want "snoop" to get notified and made available a copy of the same data that the browser read. ptrace can be used to do it, but then there are several ways the app can read data. ?It could use read(), or recv() or recvmsg(). ?Is there a better way to deal with this complexity? It's like the action of "tee" on any socket/file descriptor in the system. -- Vimal ^ permalink raw reply [flat|nested] 8+ messages in thread
* Snooping on sockets/file descriptors 2011-03-31 19:29 ` Snooping on sockets/file descriptors Vimal @ 2011-03-31 19:58 ` Daniel Baluta 2011-03-31 20:04 ` Vimal 2011-04-04 15:43 ` Florin Malita 1 sibling, 1 reply; 8+ messages in thread From: Daniel Baluta @ 2011-03-31 19:58 UTC (permalink / raw) To: kernelnewbies On Thu, Mar 31, 2011 at 10:29 PM, Vimal <j.vimal@gmail.com> wrote: > Hi, > > Is it possible for an application (say "snoop", with sufficient > privileges) to monitor data on any socket/file descriptor in the > system? > > Here's an example: ?suppose we have a browser and it creates a tcp > socket to connect to a URL. ?Whenever the browser issues a read() and > data is pushed to user space, I want "snoop" to get notified and made > available a copy of the same data that the browser read. > > ptrace can be used to do it, but then there are several ways the app > can read data. ?It could use read(), or recv() or recvmsg(). ?Is there > a better way to deal with this complexity? > > It's like the action of "tee" on any socket/file descriptor in the system. How about tcpdump? thanks, Daniel. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Snooping on sockets/file descriptors 2011-03-31 19:58 ` Daniel Baluta @ 2011-03-31 20:04 ` Vimal 2011-04-01 0:19 ` Mulyadi Santosa 0 siblings, 1 reply; 8+ messages in thread From: Vimal @ 2011-03-31 20:04 UTC (permalink / raw) To: kernelnewbies Hi Daniel, > > How about tcpdump? > Thanks for the suggestion. tcpdump is good, but it doesn't solve all problems. There are a few reasons: * TCP packets could arrive out of order * The data needn't belong to a valid TCP connection * The app could just discard data (close/flush/etc) In short, there is a lot of state and complex logic which act on the packets before it is seen by the application. Given the complexity (such as wide variations in TCP implementation), I am not sure if reimplementing them is a good idea, even if it's possible. Thanks, -- Vimal ^ permalink raw reply [flat|nested] 8+ messages in thread
* Snooping on sockets/file descriptors 2011-03-31 20:04 ` Vimal @ 2011-04-01 0:19 ` Mulyadi Santosa 2011-04-01 7:23 ` Vimal 0 siblings, 1 reply; 8+ messages in thread From: Mulyadi Santosa @ 2011-04-01 0:19 UTC (permalink / raw) To: kernelnewbies On Fri, Apr 1, 2011 at 03:04, Vimal <j.vimal@gmail.com> wrote: > Hi Daniel, > >> >> How about tcpdump? >> > > Thanks for the suggestion. > > tcpdump is good, but it doesn't solve all problems. ?There are a few reasons: > > * TCP packets could arrive out of order > * The data needn't belong to a valid TCP connection > * The app could just discard data (close/flush/etc) > > In short, there is a lot of state and complex logic which act on the > packets before it is seen by the application. then, something like dtrace or systemtap? IMO you're looking for kinda combo of kernel mode + user land "sniffer"... the user land sniffer, in it's very simple form, is by using LD_PRELOAD ... -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com ^ permalink raw reply [flat|nested] 8+ messages in thread
* Snooping on sockets/file descriptors 2011-04-01 0:19 ` Mulyadi Santosa @ 2011-04-01 7:23 ` Vimal 2011-04-01 13:34 ` Javier Martinez Canillas 0 siblings, 1 reply; 8+ messages in thread From: Vimal @ 2011-04-01 7:23 UTC (permalink / raw) To: kernelnewbies > > then, something like dtrace or systemtap? IMO you're looking for kinda > combo of kernel mode + user land "sniffer"... the user land sniffer, > in it's very simple form, is by using LD_PRELOAD ... > dtrace seems fine and is similar to ptrace. But then, one would have to enumerate all possible syscalls that the application can issue to read data. For e.g., it could use read(), recvfrom(), recvmsg(), or even syscall(syscall#, args...) I wonder if LD_PRELOAD can be done on a program without shutting it down. ptrace fits the bill here, except for the above problem. Thanks! -- Vimal ^ permalink raw reply [flat|nested] 8+ messages in thread
* Snooping on sockets/file descriptors 2011-04-01 7:23 ` Vimal @ 2011-04-01 13:34 ` Javier Martinez Canillas 2011-04-01 15:28 ` Vimal 0 siblings, 1 reply; 8+ messages in thread From: Javier Martinez Canillas @ 2011-04-01 13:34 UTC (permalink / raw) To: kernelnewbies On Fri, Apr 1, 2011 at 9:23 AM, Vimal <j.vimal@gmail.com> wrote: >> >> then, something like dtrace or systemtap? IMO you're looking for kinda >> combo of kernel mode + user land "sniffer"... the user land sniffer, >> in it's very simple form, is by using LD_PRELOAD ... >> > > dtrace seems fine and is similar to ptrace. ?But then, one would have > to enumerate all possible syscalls that the application can issue to > read data. ?For e.g., it could use read(), recvfrom(), recvmsg(), or > even syscall(syscall#, args...) > > I wonder if LD_PRELOAD can be done on a program without shutting it > down. ?ptrace fits the bill here, except for the above problem. > If you want to do it in the kernel, you can write a loadable kernel module to register netfilter hooks and obtain the socket buffers (sk_buff). Look at this blog entry: http://fcns.eu/2010/02/netfilter-hooks/ Hope it helps. Regards, ----------------------------------------- Javier Mart?nez Canillas (+34) 682 39 81 69 PhD Student in High Performance Computing Computer Architecture and Operating System Department (CAOS) Universitat Aut?noma de Barcelona Barcelona, Spain ^ permalink raw reply [flat|nested] 8+ messages in thread
* Snooping on sockets/file descriptors 2011-04-01 13:34 ` Javier Martinez Canillas @ 2011-04-01 15:28 ` Vimal 0 siblings, 0 replies; 8+ messages in thread From: Vimal @ 2011-04-01 15:28 UTC (permalink / raw) To: kernelnewbies Hi Javier, > > If you want to do it in the kernel, you can write a loadable kernel > module to register netfilter hooks and obtain the socket buffers > (sk_buff). Thanks. If you see my earlier posts, I didn't want netfilter/pcap because they give me access to packets. I would like access to the stream of data that is read by the application using read()/recvmsg()/etc syscalls. @all: thanks for the help; I think I've figured out how to do it. I manually traced the system call to see which one would be called ultimately, for read on a socket. It turns out that skb_copy_datagram_iovec(..) is called ultimately (fn defn: http://lxr.free-electrons.com/source/net/ipv4/tcp.c#L1668). I could hook onto this function using kprobes and get the data that is read. Thanks! -- Vimal ^ permalink raw reply [flat|nested] 8+ messages in thread
* Snooping on sockets/file descriptors 2011-03-31 19:29 ` Snooping on sockets/file descriptors Vimal 2011-03-31 19:58 ` Daniel Baluta @ 2011-04-04 15:43 ` Florin Malita 1 sibling, 0 replies; 8+ messages in thread From: Florin Malita @ 2011-04-04 15:43 UTC (permalink / raw) To: kernelnewbies On 03/31/11 15:29, Vimal wrote: > Is it possible for an application (say "snoop", with sufficient > privileges) to monitor data on any socket/file descriptor in the > system? "snoop" it is :) http://sourceforge.net/projects/snoop/ > Here's an example: suppose we have a browser and it creates a tcp > socket to connect to a URL. Whenever the browser issues a read() and > data is pushed to user space, I want "snoop" to get notified and made > available a copy of the same data that the browser read. For this particular scenario snoop may not be the best choice: while it can attach on-the-fly when opening local files (inotify trigger), socket FDs must be picked manually after they've been opened (/proc/<pid>/fd/...) - so unless your connection is long-lived, this is going to be tricky. -- Florin ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2011-04-04 15:43 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <AANLkTimuc_tuZ9kVJU6q6CXDzE737vZYvfrKekN+SzcM@mail.gmail.com>
2011-03-31 19:29 ` Snooping on sockets/file descriptors Vimal
2011-03-31 19:58 ` Daniel Baluta
2011-03-31 20:04 ` Vimal
2011-04-01 0:19 ` Mulyadi Santosa
2011-04-01 7:23 ` Vimal
2011-04-01 13:34 ` Javier Martinez Canillas
2011-04-01 15:28 ` Vimal
2011-04-04 15:43 ` Florin Malita
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).