不能直接拼接用户输入，因虽os/exec.command不经过shell解析，但若用sh -c包装则重引入命令注入风险；安全做法是结构化传参、白名单命令、路径规范化与校验。
用 os/exec.Command 时，为什么不能直接拼接用户输入？
因为 os/exec.Command 不会经过 shell 解析，看似“安全”，但一旦你用 sh -c 或 bash -c 包一层，用户输入就进了 shell——;、&&、|、$() 全部复活。常见错误是写成：os/exec.Command("sh", "-c", "ls " + userInput)，这和直接 system() 没本质区别。
真正安全的做法是：绕过 shell，把参数拆成独立字符串传给 Command，让操作系统直接执行二进制，不触发解析。
- ✅ 正确：
os/exec.Command("ls", "-l", "/tmp", userInput)（userInput是路径，不带空格或通配符） - ❌ 危险：
os/exec.Command("sh", "-c", "ls -l "+userInput) - ⚠️ 注意：
userInput如果含空格、星号、波浪号，即使不用sh -c，也得先做白名单校验或路径规范化（比如用filepath.Clean+strings.HasPrefix限制根目录）
如何安全地执行带动态参数的命令（如 tar 解压指定路径）？
核心原则：参数必须结构化，不能靠字符串拼接；路径必须绝对化且受限；命令二进制本身要白名单控制。
- 只允许调用预设的少数命令，比如
"tar"、"gzip"、"cp"，拒绝任何"sh"、"bash"、"python"等解释器 - 用
filepath.Join和filepath.Clean处理路径，再检查是否落在允许目录内（如/var/data/），避免../跳出 - 示例：
cmd := exec.Command("tar", "-xf", archivePath, "-C", safeDestDir, "--no-same-owner")，其中safeDestDir已通过filepath.Abs+strings.HasPrefix校验
遇到 exec: "sh": executable file not found in $PATH 就安全了吗？
不安全。这只是说明当前环境没装 sh，不代表没其他可执行解释器——dash、busybox、甚至 python 都可能被利用。更危险的是，有些容器镜像里 sh 被软链到 dash，报错消失后漏洞照旧。
- 不要依赖“报错=安全”，而要主动禁止所有解释器类命令名（正则匹配
^sh$|^bash$|^zsh$|^python.*$|^perl$|^php$） - 在
exec.Command前加一道白名单检查：if !slices.Contains(allowedCmds, cmdName) { return errors.New("command not allowed") } - 生产环境建议用
chroot或容器securityContext限制可用二进制，而非仅靠 Go 层拦截
为什么 syscall.Exec 或 exec.LookPath 不能跳过防护？
syscall.Exec 是直接替换当前进程，比 os/exec 更底层、更难监控，一旦参数可控，RCE 成功率更高；exec.LookPath 只查路径，不校验命令本身是否可信——它可能返回 /home/user/malware 这种恶意二进制。
- 禁用
syscall.Exec在服务端代码中出现，除非你在写 init 进程或调试工具 -
exec.LookPath返回的路径必须再次白名单校验（比如只允许来自/usr/bin/或/bin/下的固定文件名） - 如果必须动态找命令，用
exec.Command("which", cmdName)并解析 stdout，再对比硬编码的哈希或路径前缀
exec.Command 前完成，而不是在命令执行失败后补救**。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
