Use absolute paths when invoking built-in shell commands

[fionn]

Bug report

Bug description:

On macOS, web browsers are opened via popen calling osascript.

cpython/Lib/webbrowser.py

Line 647 in 3964f97

osapipe = os.popen("osascript", "w")

However, if a user has a colliding osascript executable earlier in their PATH, this may fail or cause unwanted behaviour.

Depending on one's environment or level of paranoia, this may be considered a security vulnerability.

CPython versions tested on:

CPython main branch, 3.13

Operating systems tested on:

macOS

Linked PRs

• gh-137586: Open external osascript program with absolute path #137584
• gh-137586: Replace 'osascript' with 'open' on macOS in webbrowser #146439
• [3.14] gh-137586: Open external osascript program with absolute path (GH-137584) #148173
• [3.13] gh-137586: Open external osascript program with absolute path (GH-137584) #148174
• [3.12] gh-137586: Open external osascript program with absolute path (GH-137584) #148175
• [3.11] gh-137586: Open external osascript program with absolute path (GH-137584) #148176
• [3.10] gh-137586: Open external osascript program with absolute path (GH-137584) #148177

[picnixz]

Note that there's also an occurrence in Lib/turtledemo/__init__.py which uses subprocess.run instead. There is also a similar occurrence in Lib/platform.py where we directly use file instead of /usr/bin/file and uname instead of /usr/bin/uname. Finally, there's another occurrence in webbrowser.py that uses xdg-settings directly.

Unless I'm mistaken, taking control over the PATH environment variable of another user is quite complex, if not impossible most of the time if we don't have enough privilieges or if the PATH is already misconfigured. Therefore, I wouldn't really count it as a security issue as the attack surface is quite small. However, I think it's better if we use full paths instead, especially for built-in commands.

It's quite hard to spot all places where we don't use an absolute path though.

[terryjreedy]

This is about a simple change of the osascript path on mac for webbrowser, its test, and in turtledemo.
@ronaldoussoren, @ned-deily can one of you verify/review the few lines of changes in the PR?

[secengjeff]

#146439 addresses this by replacing MacOSXOSAScript entirely with a new MacOSX class that uses /usr/bin/open via subprocess.run. This eliminates the osascript dependency rather than patching the path, which also resolves the broader usability problem of webbrowser.open() failing silently on managed endpoints where osascript is blocked.