Ethereal-dev: Re: [Ethereal-dev] Mac OS X support

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <gharris@xxxxxxxxx>
Date: Thu, 26 Jul 2001 00:36:00 -0700
On Wed, Jul 25, 2001 at 08:42:45PM +0200, Michael T�xen wrote:
> please find attached some patches which improve the support of Mac OS X.

Checked in, with some changes:

> - configure.in.patch
>   This patches configure.in to support the MacOS X specific compiler flag.
>   There is also a --disable-plugins options added.

Instead, I changed the "--with-plugindir" flag to be "--with-plugins";
the directory argument to that flag is now optional, and
"--without-plugins" is supported.

The default for the flag is "yes" on platforms where GLib's
"g_module_supported()" returns a non-zero value ("true"), and "no" on
platforms where it returns zero ("false").

> - tethereal.c.patch
>   This patches tethereal.c to avoid the usage of the pcap_version string
>   which is not exported in the pcap library on MacOS X.
> - gtkmain.c.patch
>   This patches gtk/main.c for the same reason as tethereal.

Perhaps these should check, instead, for "pcap_version" being defined by
libpcap, so that if you use, say, libpcap from tcpdump.org, rather than
Apple's irritating version (not defining "pcap_version" is an irritating
and, as far as I can tell, gratuitous incompatibility, unless their
shared library mechanism makes it impossible to export it, which I'd
consider an irritating incompatibility in its shared library mechanism).

> I found one problem with the --enable-setuid-option:
> If one uses the gtk library 1.2.n with n>=9 it will not work because
> the library checks this.

Yes, GTK+ 1.2.9 and later simply refuse to allow you to run GTK+
applications set-UID:

	http://www.gtk.org/faq/#AEN391

	http://www.gtk.org/setuid.html

> So it does not make much sense to have this option.

Well, Tethereal doesn't use GTK+, and it's simpler, so maybe it's safe.

However, I would *NOT* assume it's safe, and I won't commit to it being
safe to run set-UID root.  (For one thing, it doesn't give up its
set-UID privileges, so it could be used to read capture files to which
you don't have read permission....)

(Then again, I mainly use FreeBSD at home, and solve this problem
somewhat more simply:

	% ls -l /dev/bpf0
	crw-------  1 guy  wheel   23,   0 Feb  7  2000 /dev/bpf0

Linux distributions would also let you capture packets without root
privilege if they provided a mechanism for giving accounts certain
capability bits - just give CAP_NET_RAW to anybody who should be allowed
to capture packets.

See the tcpdump man page for information on other OSes:

       Reading  packets from a network interface may require that
       you have special privileges:

       Under SunOS 3.x or 4.x with NIT or BPF:
              You must have read access to /dev/nit or /dev/bpf*.

       Under Solaris with DLPI:
              You  must  have  read/write  access  to the network
              pseudo device, e.g.  /dev/le.   On  at  least  some
              versions  of  Solaris,  however, this is not suffi-
              cient to allow tcpdump to  capture  in  promiscuous
              mode;  on  those  versions  of Solaris, you must be
              root, or tcpdump must be installed setuid to  root,
              in order to capture in promiscuous mode.

       Under HP-UX with DLPI:
              You  must  be  root  or  tcpdump  must be installed
              setuid to root.

       Under IRIX with snoop:
              You must be  root  or  tcpdump  must  be  installed
              setuid to root.

       Under Linux:
              You  must  be  root  or  tcpdump  must be installed
              setuid to root.

       Under Ultrix and Digital UNIX:
              Once the super-user  has  enabled  promiscuous-mode
              operation  using  pfconfig(8), any user may capture
              network traffic with tcpdump.

       Under BSD:
              You must have read access to /dev/bpf*.

The comment about Linux reflects the lack of the ability to set
capability bits on accounts.)