Virtual environment — DedSec Project
Python virtual environment — dependency isolation versus machine isolation Definition and limits A Python virtual environment holds its own interpreter entry points and site-packages…
Python virtual environment — dependency isolation versus machine isolation
Definition and limits
A Python virtual environment holds its own interpreter entry points and site-packages location, selected via a pyvenv.cfg file and interpreter prefix. It reduces accidental dependency conflicts between projects, but does not sandbox installed packages from the operating system. A package executed inside a virtual environment can still read files and access the network with the permissions of its user. It is not equivalent to a container or a security boundary.
Portable Python 3 verification
Save this file as virtual_env_lab.py (do not name it venv.py, which would shadow the Python standard library). Run python3 virtual_env_lab.py. The example creates an isolated environment with no pip bootstrap in a disposable temporary directory, invokes its interpreter using an absolute path and compares sys.prefix against sys.base_prefix. Temporary files are cleaned up by the context manager.
import json
import os
from pathlib import Path
import subprocess
import tempfile
import venv
with tempfile.TemporaryDirectory() as directory:
target = Path(directory) / 'isolated'
venv.EnvBuilder(with_pip=False, symlinks=False).create(target)
interpreter = target / ('Scripts/python.exe' if os.name == 'nt' else 'bin/python')
assert interpreter.is_file()
probe = 'import json,sys; print(json.dumps({"prefix":sys.prefix,"base":sys.base_prefix,"path":sys.executable}))'
result = json.loads(subprocess.check_output([str(interpreter), '-c', probe], text=True))
assert Path(result['prefix']).resolve() == target.resolve()
assert result['prefix'] != result['base']
assert Path(result['path']).is_file()
print('PASS virtual environment: isolated interpreter prefix')
Why the interpreter path is reliable
The Python documentation defines sys.prefix as the active installation prefix and sys.base_prefix as the base environment. Within a virtual environment, the two normally differ. Invoking the environment interpreter by path avoids guessing whether shell activation succeeded. On Windows the interpreter is under Scripts/python.exe; on Linux/Termux it is usually under bin/python. Activation modifies shell environment conveniences, but is not required when directly invoking the interpreter. This test does not install third-party packages or use internet access.
Failure reproduction and exercises
- Deliberately rename the script venv.py in a disposable folder: observe import shadowing (missing EnvBuilder) and then rename the file. Clear any stale pycache before rerunning.
- Compare sys.executable, sys.prefix and sys.base_prefix inside/outside; write down exactly which are expected to change.
- Run python -m pip --version using the environment interpreter only when pip was installed. Explain why installing into a different Python can make an import fail.
- Explain why running untrusted pip install inside a virtual environment still poses filesystem and credential risks.
Evidence: PASS, interpreter paths from both environments, a reproduced shadowing diagnosis and the reason this feature is dependency isolation rather than a security sandbox.