Ethereal-users: Re: [Ethereal-users] errors compiling without capture support

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

Date: Wed, 26 Jan 2005 17:29:18 +0100
Wouldn't it be more simple (and effective) to make sure that non root
users cannot actually read from the devices?

#   chmod go-rwx /dev/qfe

That way only root can run snoop, tcpdump, ethereal, etc. to capture
on that machine.

Just compiling etheral without libpcap support won't defend you
against users sniffing with snoop or tcpdump and then reading their
captures with ethereal.

Luis

On Tue, 25 Jan 2005 22:35:03 -0500, Mark Sholund <msholund1@xxxxxxxxxxx> wrote:
> Hello,
> 
> I support some users who require Ethereal to be run from a shared
> location on a Solaris server.  In order to do this, I must compile
> Ethereal directly from the source.  Those that I support are not
> allowed/don't need to capture packets, only be able to read them, so I
> compile with the flag --without-pcap.  In 0.10.7 and 0.10.9, I have
> encountered problems where there is code that should be inside of
> '#ifdef HAVE_LIBPCAP' blocks.  In 0.10.9, the lines that I find these
> problems in are
> 
> gtk/main.c: 1651      capture_opts->capture_child = FALSE;
> gtk/main.c: 2409      font_init(capture_opts->capture_child);
> 
> I changed 2409 to the following
> #ifdef HAVE_LIBPCAP
>     font_init(capture_opts->capture_child);
> #else
>     font_init(FALSE);
> #endif
> 
> since 1651 shows that capture_opts->capture_child == FALSE when
> HAVE_LIBPCAP is undefined.
> 
> I get errors stating that I'm trying to access an incomplete type; from
> what I see in the source code, since HAVE_LIBPCAP is not defined
> capture_opts should be undefined which leads to that result.  I managed
> to change the code in order to get it to compile but I'm not 100%
> certain that my changes will not have consequences.  I am curious if
> anybody else has compiled without libpcap and had similar problems.  I
> am also curious if the developers compile ethereal without libpcap
> support to see if the conditional compilation blocks are well placed.
> 
> There were different but similar problems in 0.10.7.
> 
> I assume that my case is different from the majority of cases where
> Ethereal is used, i.e. most people want capture support, so this might
> not be something that is tested prior to release.  So far the problems
> that have arisen have been minor enough that I can fix them without
> delving deep into the code.
> 
> _______________________________________________
> Ethereal-users mailing list
> Ethereal-users@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-users
>