Hi Ulf, Ulf Lamping wrote: > Hi List! > > I've mostly finished the work to reimplement tshark to call dumpcap > instead of pcap directly. This implements the long awaited better > privilege seperation for tshark.
Huzzah! This is excellent news. > Some things I've already noticed that still needs a solution: > > 1) Read filters won't really work as they did before. > dumpcap don't know anything about display filter code (by definition), > so it can't handle the read filter by itself and simply writes all > packets that goes through the capture filter. With the new > implementation, I don't have a good idea to solve this in tshark - BTW > we have the same problem in Wireshark already today. I don't really understand what the problem is here: it's the whole reason we have both capture filters and read filters - capture filters are more efficient but less flexible. > 2) Event Loop polling. > tshark now has to read from a pipe to get news from dumpcap. To read > from this pipe, tshark needs a sort of an event loop. The method used in > Wireshark uses GDK specific things which are not available in "plain > glib". I've implemented a very simply loop which tries to read every > 200ms (g_usleep) from the pipe. This works for now, but we might want to > have a better implementation here in the long run. Ok. Presumably a select() on the pipe would work? Anyway this definitely sounds like something that can be fixed later. > 3) privileges > As far as I understand it, tshark will now be using normal user > privileges and calls setuid dumpcap when it starts capturing. So in the > end we won't need any special privilege dropping as it is currently > implemented in tshark? We might only want to note the user if he's > running tshark as root - but that's it with privileges in the code? Yup! Which is great. > These upcoming tshark changes should also make it possible to move all > pcap related code into dumpcap and remove any pcap code from Wireshark / > tshark (well, after some general capture code cleanup). Again I say, huzzah! Regards, Richard _______________________________________________ Wireshark-dev mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-dev
