Gerald Combs schrieb:
Ulf Lamping wrote:
Joerg Mayer schrieb:
On Mon, Aug 13, 2007 at 02:58:10PM -0700, Gerald Combs wrote:
I've submitted a patch which implements some of the changes discussed at
http://wiki.wireshark.org/Development/PrivilegeSeparation . If no one
has any objections I'd like to check it in later this week.
I'm afraid you lost me with this patch:
I understand the wireshark capture model correctly, wireshark
doesn't need root privileges even now because capturing can be done by
dumpcap, and thus wireshark should never be installed suid root. This
is reflected by configure.in.
Yes and no. While the capturing itself is already completely done in
dumpcap, some libpcap/winpcap stuff was still called in Wireshark itself
(e.g. the enumeration of capture interfaces). At least for some of the
Win32 specific stuff like the interface details windows this is still
the case AFAIR.
However, I don't know how far Geralds changes are going (didn't had a
look myself at it), maybe he fixed even that somehow.
The interface details code is still called directly from Wireshark. I
was thinking of adding an option to dumpcap to print out the details as
a list of colon-separated fields, and simply reprint them in the details
window. This would let us add detail fields to dumpcap at any time
without having to update the GTK code. What do you think?
Are we talking about the same thing? I'm referring to the "Interface
Details" dialog that pops up, when you press the Details button in the
Capture Interfaces dialog (this feature is Win32 specific!).
It would be nice to have some generic GUI code to display this, but I
have doubts that this would work well. I've attached a screenshot of the
WLAN tab, which would be very hard to do in a generic CSV way IMHO.
While I don't think it's possible to do this generic, both dumpcap and
Wireshark will know what the values mean, so the WS GUI code could
display the text (or binary?) infos from dumpcap in a graphical way like
it's already doing today - which would probably be the easiest way.
Another idea would be to seperate the interface details stuff into a
whole new GTK program, which might be the cleanest solution but some
more extra work to do ...
Regards, ULFL
