Gerald Combs wrote:
How hard would it be to fork off into privileged "capture" and
non-privileged "display" processes at program startup,
In part (except for the privileged and non-privileged part, and for the
fact that the capture part does some GUI stuff), that's how "Update list
of packets in real time" captures work.
If the subprocess were not to do any GUI stuff, but were only to send
packet counts (rather than just the single packet count it sends now)
and rely on the main process to display that (and to tell the subprocess
to stop capturing when the user asks to stop the capture), the
subprocess could be privileged...
or create a
separate (and privileged) program specifically for captures?
That program could serve the same function as the code in Ethereal to do
"Update list of packets in real time" captures does; it'd be smaller and
perhaps more worthy of being made set-UID, as necessary, on UN*X systems.
I suspect that at least *some* of the problems might have been avoided
with a higher-level language in which to write dissectors, with a
translator that takes that language and generates C code that avoids
using unsafe idioms.
Were you thinking of something similar to what we currently have with
the ASN.1 and NCP generators, or something beyond that?
Something similar. That'd mean we'd have multiple languages that can
generate dissectors, but a single language might not be appropriate for
all protocols - some protocols, such as ASN.1-based ones, already have
specifications in their own language (ASN.1, ONC RPC rpcgen, DCE RPC
IDL, etc.) or might have constraints that mean that a higher-level
language would be easier to use to describe the protocol (e.g., some of
the X11 stuff).
NetPDL:
http://analyzer.polito.it/30alpha/docs/dissectors/NetPDLSpec.htm
might be one language that could be used.
