IO plugins for libpcap

[mcr]

rebased upon master

[mcr]

Here, I think we should also depend upon WANT_IOPLUGIN, so that it can be compiled out, even if dlopen exists.

[mcr]

Do we still need this?

[mcr]

We need to have a doc/ioplugin.md

[guyharris]

There's no such header file; it was removed in 787f37e.

You need to directly include what's needed.

[guyharris]

This change is already in the main branch from commit fbb5e9e (and is unrelated to the I/O plugins).

[guyharris]

This looks as if it's not up to date with all the main branch changes, so it probably needs to be rebased.

[fxlb]

Rebased.

[fxlb]

./pcap-ioplugin.c: In function 'pcap_ioplugin_init':
./pcap-ioplugin.c:159:8: warning: unused variable 'lib' [-Wunused-variable]
  159 |  void *lib = NULL;
      |        ^~~

[guyharris]

There are several issus here.

1. On UN*X, we need either to assume we have the dlopen() APIs or check for it in CMakeLists.txt as well. It's specified in POSIX and, as far as I know, the only general-purpose UN*Xes that don't have it we're likely to encounter are 1) 32-bit HP-UX (which has its own API) and 2) perhaps older versions of AIX. However, perhaps some embedded Linux distributions have a cut-back libc that doesn't have it.
2. We're not handling Windows which has its own APIs for this.
3. If we don't have any way to load plugins, we shouldn't define a variable to hold the plugin handle.

[guyharris]

If we support plugins for writing files, and you're on a platform where packet capture requires elevated privileges, and the user can specify a plugin with an arbitrary path name with an environment variable, every program that uses the pcap dumping APIs needs to be Very Careful to surrender all elevated privileges before doing anything that causes the plugins to be loaded.

This requires some more thought.

[fxlb]

Rebased.

[infrastation]

If the only functions implemented by a plugin would be a custom read function and a custom write function, would it be simpler to use popen() instead? For example, tar allows a number of different compression filters, each of which runs as a separate process.

[infrastation]

the-tcpdump-group/tcpdump#458 seems to implement a similar idea, although the code seems a bit more complicated than I thought and uses fork() + execvp() instead of popen().

[infrastation]

the-tcpdump-group/tcpdump#935 is yet another alternative implementation.