Why is it risky to run a Python script from a world-writable directory?

## The entry that causes it Before your first line runs, CPython assembles `sys.path`, the ordered list of directories the import machinery searches. When the interpreter is launched with a script path — `python /srv/jobs/job.py` — it prepends **the directory containing that script** as `sys.path[0]`. (Since 3.11 that entry is the absolute, fully resolved directory; earlier versions inserted it as written.) Everything else follows: any `PYTHONPATH` entries, then the standard library, then the `site-packages` directory of the environment in use. The ordering is the whole story. Import resolution walks `sys.path` front to back and stops at the first match. Only modules that are built into the interpreter or frozen into it — `sys` and the import bootstrap itself — are resolved before the path is consulted at all. Everything else, including `json`, `logging`, `random`, `socket` and `email`, is an ordinary file that the search finds somewhere on the path, and `sys.path[0]` gets first refusal on the name. ## Why 'first' is a security property, not just a gotcha A developer usually meets this ordering as an accident: a helper file next to the script wins over a same-named library module. The security version of the same mechanic asks a different question — **who else can create files in that directory?** An import is not a data read. Importing a module *executes* its top-level code: assignments, decorators, `open()` calls, network calls, anything. So an attacker who can write into `sys.path[0]` does not need to find a bug in your program. They need only to guess one module name your script imports and leave a file with that name. The moment the process reaches the import statement — typically in the first milliseconds, long before argument parsing or any authorization check — their code runs inside your process, as your user, with your environment, your credentials and your file handles. The guessing part is easy. Almost every script imports `os`, `sys`, `json`, `logging`, `re`, `time` or `pathlib`. `sys` is built in and cannot be shadowed this way, but the rest are ordinary files on the path and are all fair game. ## Where this actually happens * A shared scratch directory such as `/tmp/work` that several accounts or several containers write into, where an operations script is dropped and executed. * A downloads directory: you fetch a one-off tool and run it in place, in a folder every other download also lands in. * A deploy or job directory whose permissions drifted to world-writable — the classic case, because the code there is run repeatedly and often by a privileged service account. * A queue or spool directory where one component writes files and another runs a script from the same location. If, say, the rollback step of a log-ingest pipeline is executed from the same folder the pipeline drops rejected batches into, the attack surface and the data surface are the same directory. Note the difference from an environment-variable attack: nothing is injected into the process's configuration here. The path entry is one CPython adds by design; the attacker only supplies a file. ## Reducing it **Fix the directory first.** The real defect is a directory that is both writable by others and used as a working directory for executed code. Run scripts from a location owned by the account that runs them, mode `0755` or tighter, and treat a world-writable directory as untrusted input. **Then drop the entry.** Python 3.11 added a way to say 'do not put my launch directory on the path': the `-P` command-line flag, or the `PYTHONSAFEPATH` environment variable set to a non-empty value. Either one is readable at runtime as `sys.flags.safe_path`. With it set, `sys.path[0]` is no longer the script's directory (and, for `-c` and the REPL, no longer the current directory), so a dropped file beside the script is simply not found. `-I` (isolated mode) implies the same behaviour and additionally ignores `PYTHON*` variables and the user site directory — a good default for a tool run by a service. The cost is that the script can no longer import its own sibling helper modules by bare name, which is exactly why it is opt-in rather than the default. Code that must keep working under `-P` should live in an installed distribution and be imported by its package name, not found by proximity. **Verify what you got.** `importlib.util.find_spec(name).origin` tells you the file an import would actually load, and `module.__file__` tells you where a loaded one came from. In a suspected incident, print those for the modules the script imports rather than assuming the standard library won. ## What this does not cover `-P` says nothing about `PYTHONPATH` (use `-E` or `-I` for that), nothing about a writable `site-packages` in a shared environment, and nothing about a script that changes directory at runtime. It removes exactly one entry — the one that makes 'where the file happens to sit' into a privilege.