Wireshark-dev: Re: [Wireshark-dev] tshark: drop features "dump to stdout" and "read filter"
From: Kirby Files <[email protected]>
Date: Tue, 09 Oct 2007 09:42:21 -0400
Ulf Lamping wrote on 10/09/2007 02:50 AM:
 > 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.
But we could still dump to a file, right? If you're proposing removing 
-w entirely and pushing this usage to dumpcap, that's not a great 
solution for me. I don't understand why this would be difficult to 
accomplish with privilege sep. Couldn't dumpcap just handle the 
capture, and tshark write the dump file? What output pipe does tshark 
have that will get messed up?
We frequently use -w and -R to capture specific packet streams (with 
filters not supported by pcap, like -R mpls.label==300; even filters 
supported by pcap work better with read filters, like vlan.id==100, 
which pcap doesn't support if the VLANs are inside MPLS encap).
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).
Yikes! This would really hurt. As above, we use read filters almost 
exclusively. We would at least need to be able to do this:
dumpcap -i eth2 > packets.cap

tethereal -r packets.cap -R mpls.label==300 -w filtered.cap

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 ...
Is there a problem keeping read filters for tshark as used in my 
example above, where we're just processing a dump file? There's no 
security issue there, as tshark doesn't need root privileges when it's 
not attaching to a socket, right?
Bottom line: I cannot really live without read filters, and it would 
be awfully inconvenient to switch to dumpcap instead of tshark for 
dumping a file -- not a show-stopper (users can eventually be 
trained), but a pain. This really seems to be more about syntax than 
whether or not it's possible to retain -w and -R, isn't it? The new 
privsep architecture leaves the capture to the privileged dumpcap, 
pipes all of the packets to tshark, which should be able to implement 
read filters and output dumping without privileges.