Wireshark-dev: [Wireshark-dev] tshark: drop features "dump to stdout" and "read filter"
From: Ulf Lamping <[email protected]>
Date: Tue, 09 Oct 2007 08:50:59 +0200
Hi List!

I had a look at the tshark buildbot test problems and found two things that are currently not working as before. But let me shortly explain what's going on "under the hood" with the "new" privilege seperation:
Just as Wireshark is doing it already for some time, tshark now also use 
dumpcap to capture stuff (to seperate the "potential dangerous" 
dissection from the "root required" capturing). tshark calls dumpcap 
with a set of command line options (capture interface, capture file 
name, ...) and establishes a pipe to dumpcap. Now dumpcap captures 
packets into a temporary file, a named file or some ringbuffer files and 
notices tshark events through a pipe, e.g. a new file was opened, some 
packets rushed in, ...

Now the two problems in the buildbot test are:

a) dumping to stdout (using -w -)
Dumping to stdout will mix up with the pipe (standard-)output, so this cannot work as before. BTW: Wireshark cannot capture to stdout for the same reason (or am I missinformed here?).
Solution: to dump to stdout, use dumpcap - it's build for that purpose. 
Document that dumping to stdout doesn't work with tshark / Wireshark and 
prevent "-w -" command line option.

b) read filter
dumpcap doesn't know anything about display filter syntax - to gain better security (that's explicitly the difference between tshark and dumpcap!). So dumpcap cannot filter out that stuff and will dump everything it get's to the output file. As the resulting capture file contains "all packets" now, everything filtered now is a "sort of" display filter anyway - so the concept of a read filter doesn't really work here ...
Solution: Drop read filters completely, they don't really fit in the 
concept of privilege seperation. Document the change and prevent the 
according command line option(s).

Please note: I'm not argueing against the usefullness of both options, but they don't fit into the idea of privilege seperation and the current implementation of it. So I don't see a good way to "re-"implement them ...
Regards, ULFL