https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15710

            Bug ID: 15710
           Summary: extcap: Python scripts are not executed on Windows
           Product: Wireshark
           Version: Git
          Hardware: All
                OS: Windows
            Status: CONFIRMED
          Severity: Normal
          Priority: Low
         Component: Common utilities (libwsutil)
          Assignee: bugzilla-ad...@wireshark.org
          Reporter: pe...@lekensteyn.nl
                CC: deso...@gmail.com, lom...@gmail.com
  Target Milestone: ---

Build Information:
Paste the COMPLETE build information from "Help->About Wireshark", "wireshark
-v", or "tshark -v".
--
Copying the sample .py extcap utility does enable the interface on Windows,
macOS and Linux works normally.

To reproduce:

 mkdir extcapdir
 cp test\sampleif.py extcapdir
 $Env:WIRESHARK_EXTCAP_DIR="$PWD\extcapdir"
 $Env:G_MESSAGES_DEBUG="all"
 tshark -D

Expected results (Linux):

 (process:19931): Capture-DEBUG: 13:41:34.378: spawn params: 
--extcap-interfaces --extcap-version=3.1
 (process:19931): Capture-DEBUG: 13:41:34.412:
/tmp/wsbuild/extcapdir/sampleif.py finished in 34.037ms
 (process:19931): Capture-DEBUG: 13:41:34.412: spawn output: extcap
{version=1.0}
interface {value=sampleif}{display=Remote dumpcap}
 ...
 13. sampleif (Remote dumpcap)

Actual results (Windows):

 (tshark.exe:2480): Capture-DEBUG: spawn params:  --extcap-interfaces
--extcap-version=3.1
 (tshark.exe:2480): Capture-DEBUG: E:\\wsbuild\\extcapdir\\sampleif.py finished
in 0,000ms
 (tshark.exe:2480): Capture-DEBUG: spawn params:  --extcap-interfaces
 (tshark.exe:2480): Capture-DEBUG: E:\\wsbuild\\extcapdir\\sampleif.py finished
in 0,000ms
 (tshark.exe:2480): Capture-DEBUG: extcap: completed discovery of 1 tools in
0,000ms

(Note missing command output.)

While discussing https://code.wireshark.org/review/32754, Tomasz Moń writes:

> It is likely that the function that looks for extcaps already finds .py
> files if the configured .py file integration on Windows. It can be
> easily checked by looking at the PATHEXT environment variable.
>
> The limitation is that win32_create_process() in win32-utils.c is not
> aware of how to execute scripts that CreateProcess() cannot execute
> directly. That is, having the .py present in PATHEXT does not make
> CreateProcess() aware of how to launch them.
>
> One possibility would be to modify win32_create_process() to try
> CreateProcess() and if it fails, check if extension is in PATHEXT and if
> it is, then use AssocQueryString to look for the executable and prepend
> the executable to the supplied commandline. This however, just like the
> overlapped I/O, is quite simple in high level talk, but not so easy to
> actually implement it right.
>
> Having said that, I perfectly understand why the person who came up with
> the .bat wrapper idea, just wrote it in the documentation - as it gets
> the job done with (what I would consider) only a minor annoyance. 

Indeed, I do have ".py" in PATHEXT, so extcap_get_extcap_paths (extcap.c) does
pass the g_file_test(extcap_path, G_FILE_TEST_IS_EXECUTABLE) check and
therefore tries to execute it.

Digging through the git logs for the WSDG recommendation to create a batch
file, it looks like Dario added it first via doc/README.extcap (which
subsequently got incorporated into the WSDG).

Use of AssocQueryString to lookup the program associated with an extension
could work, but I am worried that on systems without Python installed (or a
different default), it could end up opening a text editor for example. So some
kind of whitelist would be needed.

In that case, what do you think about special casing Python support? If the
extension is .py, lookup the Python interpreter (maybe in PATH for simplicity?)
and use it. This does mean that if the user wants to use Lua, Perl or any other
scripting language, then they would have to create a similar patch for
Wireshark to support it out-of-the-box without a batch script.

-- 
You are receiving this mail because:
You are watching all bug changes.
___________________________________________________________________________
Sent via:    Wireshark-bugs mailing list <wireshark-bugs@wireshark.org>
Archives:    https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
             mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

Reply via email to