On Jul 31, 2014, at 3:11 PM, Peter Wu <peter@xxxxxxxxxxxxx> wrote:
> On Thursday 31 July 2014 17:11:59 Evan Huus wrote:
>> This issue has been bugging me for a while, but I also haven't been able to
>> come up with a satisfactory solution.
>
> Oh my, that filesystem.c code is really ugly and relying on a lot of
> assumptions. Why does it need to distinguish build dirs from other dirs in the
> first place?
So that you can just type "./wireshark" or "./tshark" after you've done a build, and have it Just Work, rather than having to install Wireshark or TShark before you can run it. Note that we run TShark to generate some man pages.
> From the comments, it seems to that for security/stability
> reasons,
From one of the comments:
/*
* Check whether WIRESHARK_RUN_FROM_BUILD_DIRECTORY is set in the
* environment; if so, set running_in_build_directory_flag if we
* weren't started with special privileges. (If we were started
* with special privileges, it's not safe to allow the user to point
* us to some other directory; running_in_build_directory_flag, when
* set, causes us to look for plugins and the like in the build
* directory.)
*/
So the code that sets the "running from the build directory flag" takes into account security issues, but it doesn't *exist* for security reasons.
On the other hand, from doc/README.packaging:
WIRESHARK CONTAINS OVER TWO MILLION LINES OF SOURCE CODE. DO NOT RUN THEM AS ROOT.
so perhaps, when the user clicks "OK" to the
Running as user "root" and group "wheel".
This could be dangerous.
If you're running Wireshark this way in order to perform live capture, you may want to be aware that there is a better way documented at
http://wiki.wireshark.org/CaptureSetup/CapturePrivileges
dialog we pop up when you run Wireshark as root, we should just exist, and force them to stop doing that. (And TShark should print the same message and just exit.)
However, "running as root or group 0" isn't the only flavor of elevated privileges, so we should probably enforce "no loading of plugins from anything other the install directory" in those cases as well.
> and another reason is to make plugins get loaded from the build dir.
Not just plugins, but also global configuration files, etc..
> What about solely relying on envvars?
Sure, as long as the user doesn't have to do anything to set the environment variable. Otherwise, it doesn't Just Work.
> Then there can be a shell-script if you
> like the wrapper provided by libtool:
>
> #!/bin/bash
> # tools/run.sh - Wrapper for binaries
> # since Mac does not have `readlink -f`, this is an alternative:
Neither do older versions of other BSD-flavored OSes. I guess Apple just haven't updated readlink in a while.
> rundir=$(cd "$(dirname "$0")" && pwd)
> #rundir=$(dirname "$(readlink -f "$0")")
> export WIRESHARK_DATA_DIR=$rundir
> export WIRESHARK_PLUGIN_DIR=$rundir
> #etc.
> exec "$rundir/${0##*/}" "$@"
>
> With links:
> tmpbin/tshark -> ../tools/run.sh
> tmpbin/wireshark -> ../tools/run.sh
> etc.
So tmpbin is the top-level source directory, so running "./tshark", "./wireshark", etc. from the top-level CMake build directory would be sufficient?
