shell=True是多数安全问题的源头，因其将命令交由系统shell解析，使用户输入中的;、&&、$()等可触发任意命令执行；正确做法是禁用shell=True，改用列表传参如subprocess.run(["ls", "-l", user_input])，让Python直接调用程序、绕过shell解析。
为什么shell=True是多数安全问题的源头
直接传字符串给subprocess.run()并设shell=True，等于把命令交给系统 shell 解析——这时user_input里只要含;、&&、$()或$(rm -rf /)这种东西，就可能执行任意命令。shell=True只应在你完全控制命令字符串、且明确需要 shell 特性（如管道、通配符展开）时才用。
绝大多数场景下，应该用列表形式传参，让 Python 直接调用程序，绕过 shell：
subprocess.run(["ls", "-l", "/tmp"]) # 安全
subprocess.run("ls -l /tmp", shell=True) # 危险，尤其当路径来自用户输入时- 参数必须是字符串列表，每个元素对应一个命令行参数，不拼接、不解释
- 路径含空格或特殊字符？没问题，
["cp", "my file.txt", "/dest/"]照常工作 - 环境变量扩展（如
$HOME）不会自动发生，得自己用os.path.expandvars()
如何正确传递用户输入的参数
用户输入进命令行，最常见错误是用str.format()或f-string拼接字符串再塞给shell=True。这几乎必然导致命令注入。
正确做法：把用户输入作为独立列表元素传入，由操作系统原样传递给目标程序：
立即学习“Python免费学习笔记（深入）”；
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
user_file = input("Enter filename: ") # 假设用户输的是 `; rm -f *.py`
subprocess.run(["cat", user_file]) # cat 程序收到的参数就是字面量 "; rm -f *.py"，不会执行- 永远不要对用户输入做
"cat " + user_file这类拼接 - 如果用户输入需参与路径构造，先用
os.path.join()或pathlib.Path()规范路径，再转成字符串加入参数列表 - 需要过滤或校验？比如只允许字母数字和下划线：
re.match(r'^[a-zA-Z0-9_]+$', user_input)，但别依赖正则“消毒”后拼字符串
subprocess.run() vs subprocess.Popen()怎么选
subprocess.run()适合一次性执行、等待完成、获取返回码和输出；subprocess.Popen()适合需要交互、流式读取、或长期运行的子进程。
安全上二者无本质区别，关键都在参数传法：
- 用
run()时，确保capture_output=True而非stdout=subprocess.PIPE加shell=True混用 - 用
Popen()时，避免stdin=subprocess.PIPE后直接.communicate(input=user_data)——除非你确认目标程序能安全处理任意二进制输入 - 若要限制资源（如超时、内存），
run(timeout=5)比手动poll()更可靠；超时后子进程默认不被杀，需加kill_on_timeout=True（Python 3.12+）或手动.kill()
环境与编码问题经常被忽略
子进程的LANG、PATH可能和当前 Python 进程不同，导致命令找不到，或输出乱码。尤其在 Docker 或 CI 环境中更明显。
- 显式指定
env参数，至少继承当前环境：env=os.environ.copy()，再按需修改 - 中文路径或输出出错？加
encoding="utf-8"，否则run(..., text=True)可能用系统默认编码（如 Windows 的 cp1252）解码失败 - 想禁用所有环境变量（最小权限）？用
env={}，但记得手动加PATH，否则ls都找不到
真正麻烦的不是语法写错，而是以为“没报错=安全”，结果在特定输入或环境下才触发漏洞。参数列表、显式编码、最小化环境，三者缺一不可。
