禁用open系统调用时获取完整Python Traceback信息的方法及open与write同时放行的安全性疑问

首先，咱们先解决不用放行open就能拿到完整traceback的问题——其实根本不需要开open权限，因为Python启动时已经默认打开了stdout和stderr这两个文件描述符，而你的syscall列表里已经允许了write，完全可以利用这一点来输出错误信息。

具体做法很简单：把用户的代码包裹在try-except块里，用Python的traceback模块手动捕获并打印异常信息。因为输出到已打开的stderr/stdout只需要调用write，不会触发open系统调用。修改后的代码大概是这样：

import sys
from seccomp import *
import traceback  # 导入traceback模块

# ... 你的seccomp规则加载代码保持不变 ...

# 包裹用户代码并处理异常
try:
    # User's code, triggers ZeroDivision
    a = 10 / 0
except Exception:
    # 直接打印完整traceback到stderr，只用write系统调用
    traceback.print_exc()

这样用户就能看到完整的错误栈信息，而且完全不需要放行open，安全性不受影响。

接下来聊聊放行open+write的安全性：这绝对是有风险的，不建议直接这么做。不可信代码拿到open权限后，能读取容器内的敏感文件（比如/etc/passwd、挂载的配置文件），如果容器内目录有写权限，还能创建/修改文件，甚至可能利用某些文件操作漏洞尝试容器逃逸——哪怕是在Docker环境里，这种权限放开的风险也不可忽视。

如果实在有场景需要允许文件操作，也不能直接放行所有open调用，得做严格限制：

• 用seccomp规则过滤open的参数，比如只允许以只读模式打开（检查O_RDONLY标志），或者限制只能打开特定前缀的路径（比如/tmp/下的文件）；
• 配合Docker的文件系统权限配置，把代码运行目录设为只读，只给临时目录（比如/tmp）有限的写权限；
• 注意seccomp的路径过滤存在绕过可能（比如符号链接），需要结合其他安全机制（如AppArmor或SELinux）来加固。

总之，优先用捕获异常输出到stdout/stderr的方案，既满足需求又不降低安全性；放行open是下下策，必须做多层安全防护才能尝试。

备注：内容来源于stack exchange，提问作者Chengyuan Zhang