Re: Passing the PCAP file descriptor to another

[Sebastien Raveau <sebastien.raveau () epita fr>]

On Monday 23 October 2006 10:27, Guy Harris wrote:
> > *   first I have to include the pcap-int.h file in order to be able to mess
> >     with Libpcap's internals, starting with pcap_t::fd, and as you (may not)
> >     know this file never gets installed in /usr/include :)
>
> ...because libpcap's internals are subject to change from release to
> release.

I know :) I wasn't contesting that, just pointing it out...

> > *   then there's not much I can do with it: running unprivileged, my only
> >     options are to call pcap_open_dead() or pcap_open_offline(),
>
> ...neither of which can handle live capturing [...]

My point exactly.

> > So, in order for PCAP-file-descriptor-passing-between-processes to be
> > usable (as in "deployed software") it appears that the only way would be
> > to add support for it directly in Libpcap, and I was hoping we could
> > discuss "how exactly" on this mailing list before I start implementing it
> > :)
>
> pcap_fdopen_live()?
> [...]
> This means that more information than is available from a file
> descriptor might be necessary in order to construct a pcap_t.

Indeed, which is why I was more thinking of implementing the whole "passing" 
thing inside Libpcap in the form of two functions pcap_send_context() and 
pcap_recv_context(), rather than just one pcap_fdopen_live().

pcap_send_context() would take a connected PF_UNIX socket and a pointer to an 
initialized pcap_t structure, and would send all the necessary information to 
recreate that PCAP context on the other end.

pcap_recv_context() would take a connected PF_UNIX socket only, but it would 
return a coherent pcap_t structure according to what's been received from the 
sender process, blocking in the meantime.

Of course both will have a means of reporting errors, probably (int)-1 in the 
case of pcap_send_context() and NULL in the case of pcap_recv_context().

> The way we'll probably end up handling this in Wireshark is to have the
> (potentially-)privileged program not only open the device but open the
> output file and write to it (after permanently relinquishing its
> privileges), with Wireshark reading the file based on information sent
> to it from the capture program over a pipe (that mechanism is already
> there - we just don't have the privilege separation there).

That's how we implemented it in hawKeye (prior to knowing that it was possible 
to pass FDs in UNIX) but it's terrible performance-wise... at least for us :)

-- 
Sébastien Raveau
computer and network security student
head of the hawKeye network monitor project
http://hawkeye.sourceforge.net/

Attachment: _bin
Description: