Hi Ulf,

a question inline...

Best regards
Michael
On Oct 9, 2007, at 8:50 AM, Ulf Lamping wrote:

> 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
I agree, no display filters in dumpcap.
> 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 ...
What is a read filter? I think we should continue to support the
capture filters.
>
> 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
> _______________________________________________
> Wireshark-dev mailing list
> [email protected]
> http://www.wireshark.org/mailman/listinfo/wireshark-dev

_______________________________________________
Wireshark-dev mailing list
[email protected]
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Reply via email to