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/
pgplzoKd7c8Ts.pgp
Description: PGP signature
