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
