WSL2下Docker Compose启动容器内Terminator失败及无特权方案问询

报错gi.repository.GLib.GError: g-io-error-quark: Failed to execute child process "/bin/bash": Failed to fdwalk: Operation not permitted (14)的核心原因是配置中开启了pid: host让容器共享宿主机PID命名空间，Docker默认的seccomp安全规则会拦截该场景下VTE（Terminator依赖的终端底层组件）fork shell进程时调用的fdwalk相关逻辑。
你手动执行docker run时加了--privileged参数，该参数会绕过所有seccomp、AppArmor等安全限制所以能正常运行；而docker-compose配置中仅关闭了AppArmor，没有放开seccomp限制，也没有授予全特权，因此触发权限拦截。

无需开启privileged: true全特权模式，任选以下一种方案即可修复：

• 方案1（最小改动，推荐）：在公共配置的security_opt块下新增seccomp关闭配置，仅放开系统调用拦截，不授予额外特权：

security_opt:
  - apparmor:unconfined
  - seccomp:unconfined

该配置的安全风险远低于全特权模式，足够覆盖Terminator运行所需的系统调用权限。

• 方案2：如果你没有让容器共享宿主机进程树的明确需求，直接删除公共配置中的pid: host行即可。
  Terminator本身不依赖宿主机PID命名空间，删除后容器使用独立PID命名空间，默认seccomp规则不会拦截容器内部进程的fdwalk调用，可直接正常启动。
• 方案3（高安全要求场景使用）：如果不希望完全关闭seccomp，可以基于Docker官方默认seccomp配置文件，单独添加pidfd_open等跨PID命名空间操作所需的系统调用白名单，启动时指定自定义seccomp配置文件即可，日常使用前两种方案完全满足需求。

修改配置后执行sudo docker-compose up，Terminator可正常启动弹出窗口，无fdwalk相关报错。

内容的提问来源于stack exchange，提问作者Lando1784