In subprocess on Windows, why is an argument list a weaker boundary than on POSIX?

## The two process-creation models The reason an argument list is a real security boundary on Linux is not the Python API — it is the kernel interface underneath it. The exec family takes an array of strings, and the child's `argv` is that array. There is no string in between, so there is nothing for a metacharacter to be a metacharacter in. Python's list form is a thin, faithful wrapper over that. Windows creates processes from a single command-line string. The list you pass to `subprocess.Popen` therefore cannot be handed to the operating system as-is: CPython joins it into one string with `subprocess.list2cmdline`, and the child — not the OS — splits that string back into arguments. The boundary has moved from the kernel into a convention that both sides must agree on. ## What `list2cmdline` implements `subprocess.list2cmdline` encodes the quoting rules of the Microsoft C runtime's command-line parser, the code that produces `argv` for a C program before `main` runs. In outline: an argument containing a space or tab is wrapped in double quotes; a literal double quote is escaped with a backslash; a run of backslashes immediately preceding a quote is doubled; backslashes elsewhere are left alone. It is available on every platform, so you can inspect exactly what a Windows child would be handed without owning a Windows machine. Notice what the rules do *not* cover. They quote for word splitting, not for anything else. `&`, `|`, `^`, `<`, `>` and `%VAR%` pass through untouched — which is correct, because a normal executable started directly never sees a shell and those characters mean nothing to it. ## Where the convention breaks The convention holds only while the child parses by the same rules. Two categories break it. Programs with hand-rolled command-line parsing, including some ported tools and runtimes with their own conventions, split the string their own way. A value that `list2cmdline` believed it had bounded can then become two arguments, or an option. More importantly, batch files. A `.bat` or `.cmd` file is not an executable; it is run by the command interpreter, so the command line reaches `cmd.exe`, whose parsing came from a different lineage entirely. `cmd.exe` performs `%`-expansion before argument splitting, honours `&`, `|` and `^` as command syntax, and does not treat a double quote the way the C runtime does in every position. Untrusted text passed as an argument to a batch file is therefore closer to the `shell=True` situation than to the argument-list one, even though your Python code contains a list. The standard library documentation says this in so many words: on Windows the sequence is converted to a string, and not all applications interpret the command line the same way. And `shell=True` on Windows means `cmd.exe /c` — the interpreter named by `COMSPEC` — with all of the above live by design. ## What this looks like in practice Take a nightly payment reconciliation job that shells out to a converter for each statement file, passing the customer-supplied filename as one element of a list. On the Linux container where it was written and tested, the list form makes filename content inert: a name containing `&` is just an odd name. The same job is later scheduled on a Windows agent, where the converter is shipped as a `.bat` wrapper around the real executable. Nothing in the Python diff changed — the call site is still a list, the review still reads clean — but the argument now flows through `cmd.exe`, and a filename crafted to contain `&` can append a command. Injection defences that were tested only on the platform the developer used are not defences on the platform the job runs on. The fixes are structural, not textual. Invoke the real executable rather than its batch wrapper, so no interpreter is involved. Allow-list the program and resolve it to an absolute path. Validate untrusted filenames against a strict pattern, or better, never let the external name reach the command line at all: copy the file to a name you generate and pass that. Do not look for a Windows equivalent of `shlex.quote` — the module models POSIX lexing and there is no standard-library counterpart, which is the standard library telling you to avoid building the string. ## What the interviewer is checking The weak answer is "use a list, that's it", learned as a rule with no model behind it. The strong one names the process-creation difference, names `subprocess.list2cmdline` as the code that fills the gap, identifies batch files and non-conforming parsers as where the convention fails, and treats "tested on Linux, deployed on Windows" as an unverified claim.