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。这几乎必然导致命令注入。

正确做法：把用户输入作为独立列表元素传入，由操作系统原样传递给目标程序：

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()适合需要交互、流式读取、或长期运行的子进程。

macOS UI 自动化技能包 —— 用 Python 控制你的 Mac

让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限

下载

安全上二者无本质区别，关键都在参数传法：

• 用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都找不到

真正麻烦的不是语法写错，而是以为“没报错=安全”，结果在特定输入或环境下才触发漏洞。参数列表、显式编码、最小化环境，三者缺一不可。

Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！