Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PYTHONSAFEPATH still includes the current directory on Windows for script entrypoints #131484

Open
nedbat opened this issue Mar 19, 2025 · 0 comments
Labels
triaged The issue has been accepted as valid by a triager. type-bug An unexpected behavior, bug, or error

Comments

@nedbat
Copy link
Member

nedbat commented Mar 19, 2025

Bug report

Bug description:

We tried to support PYTHONSAFEPATH in coverage.py (pull request), and had a problem where Windows didn't behave the same as MacOS or Linux. I decided to make a small test repo for checking how it behaved natively in Python, and I think I've found a discrepancy.

The test repo is here: https://github.com/nedbat/safe-path-tests

The code prints a number of values from the sys module. Tox and GitHub Actions are used to run the code in a number of different ways on all three operating systems. Below are excerpts from the action runs, with links to the appropriate spots in the full runs.

When installing the code as an executable script entrypoint and run normally, the first entry in sys.path indicates the source of the code:

Windows (full action run):

py311: commands[21]> safepathtests
================================================================================
3.11.9 (tags/v3.11.9:de54cf5, Apr  2 2024, 10:12:12) [MSC v.1938 64 bit (AMD64)]
sys.argv = ['D:\\a\\safe-path-tests\\safe-path-tests\\.tox\\py311\\Scripts\\safepathtests.EXE']
os.getcwd() = 'D:\\a\\safe-path-tests\\safe-path-tests'
__file__ = 'D:\\a\\safe-path-tests\\safe-path-tests\\.tox\\py311\\Lib\\site-packages\\safepathtests\\work.py'
sys.path:
  0: D:\a\safe-path-tests\safe-path-tests\.tox\py311\Scripts\safepathtests.EXE
  1: C:\hostedtoolcache\windows\Python\3.11.9\x64\python311.zip
  2: C:\hostedtoolcache\windows\Python\3.11.9\x64\DLLs
  3: C:\hostedtoolcache\windows\Python\3.11.9\x64\Lib
  4: C:\hostedtoolcache\windows\Python\3.11.9\x64
  5: D:\a\safe-path-tests\safe-path-tests\.tox\py311
  6: D:\a\safe-path-tests\safe-path-tests\.tox\py311\Lib\site-packages

sys.flags:
  ignore_environment: 0
  isolated: 0
  safe_path: False

MacOS (full action run):

py311: commands[21]> safepathtests
================================================================================
3.11.9 (v3.11.9:de54cf5be3, Apr  2 2024, 07:12:50) [Clang 13.0.0 (clang-1300.0.29.30)]
sys.argv = ['/Users/runner/work/safe-path-tests/safe-path-tests/.tox/py311/bin/safepathtests']
os.getcwd() = '/Users/runner/work/safe-path-tests/safe-path-tests'
__file__ = '/Users/runner/work/safe-path-tests/safe-path-tests/.tox/py311/lib/python3.11/site-packages/safepathtests/work.py'
sys.path:
  0: /Users/runner/work/safe-path-tests/safe-path-tests/.tox/py311/bin
  1: /Library/Frameworks/Python.framework/Versions/3.11/lib/python311.zip
  2: /Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11
  3: /Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/lib-dynload
  4: /Users/runner/work/safe-path-tests/safe-path-tests/.tox/py311/lib/python3.11/site-packages

sys.flags:
  ignore_environment: 0
  isolated: 0
  safe_path: False

But when run with PYTHONSAFEPATH=1, Windows still has the same first entry in sys.path while MacOS is missing it. I would expect it to be missing:

Windows (full action run):

py311: commands[22]> env PYTHONSAFEPATH=1 safepathtests
================================================================================
3.11.9 (tags/v3.11.9:de54cf5, Apr  2 2024, 10:12:12) [MSC v.1938 64 bit (AMD64)]
sys.argv = ['D:\\a\\safe-path-tests\\safe-path-tests\\.tox\\py311\\Scripts\\safepathtests']
os.getcwd() = 'D:\\a\\safe-path-tests\\safe-path-tests'
__file__ = 'D:\\a\\safe-path-tests\\safe-path-tests\\.tox\\py311\\Lib\\site-packages\\safepathtests\\work.py'
sys.path:
  0: D:\a\safe-path-tests\safe-path-tests\.tox\py311\Scripts\safepathtests.exe
  1: C:\hostedtoolcache\windows\Python\3.11.9\x64\python311.zip
  2: C:\hostedtoolcache\windows\Python\3.11.9\x64\DLLs
  3: C:\hostedtoolcache\windows\Python\3.11.9\x64\Lib
  4: C:\hostedtoolcache\windows\Python\3.11.9\x64
  5: D:\a\safe-path-tests\safe-path-tests\.tox\py311
  6: D:\a\safe-path-tests\safe-path-tests\.tox\py311\Lib\site-packages

sys.flags:
  ignore_environment: 0
  isolated: 0
  safe_path: True

MacOS (full action run):

py311: commands[22]> env PYTHONSAFEPATH=1 safepathtests
================================================================================
3.11.9 (v3.11.9:de54cf5be3, Apr  2 2024, 07:12:50) [Clang 13.0.0 (clang-1300.0.29.30)]
sys.argv = ['/Users/runner/work/safe-path-tests/safe-path-tests/.tox/py311/bin/safepathtests']
os.getcwd() = '/Users/runner/work/safe-path-tests/safe-path-tests'
__file__ = '/Users/runner/work/safe-path-tests/safe-path-tests/.tox/py311/lib/python3.11/site-packages/safepathtests/work.py'
sys.path:
  0: /Library/Frameworks/Python.framework/Versions/3.11/lib/python311.zip
  1: /Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11
  2: /Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/lib-dynload
  3: /Users/runner/work/safe-path-tests/safe-path-tests/.tox/py311/lib/python3.11/site-packages

sys.flags:
  ignore_environment: 0
  isolated: 0
  safe_path: True

The pattern continues in Python 3.12 and 3.13 as well. Linux behaves as MacOS does.

Is this correct behavior? Why does Windows keep the first sys.path entry when MacOS and Linux do not?

BTW: #123121 sounds similar, but I don't know if it's related.

Let me know if any of this is unclear, I'll try to explain. The test repo gets a bit intricate.

CPython versions tested on:

3.11, 3.12, 3.13

Operating systems tested on:

Linux, macOS, Windows

@nedbat nedbat added the type-bug An unexpected behavior, bug, or error label Mar 19, 2025
@picnixz picnixz added the triaged The issue has been accepted as valid by a triager. label Mar 22, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
triaged The issue has been accepted as valid by a triager. type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

No branches or pull requests

2 participants