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. Thanks, --kirby _______________________________________________ Wireshark-dev mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-dev
