Docker Compose启动容器时非sudo无法运行SDK脚本问题排查

问题根源分析 #

1. 网络命名空间权限限制
   docker run默认以root用户启动容器，而docker-compose明确指定user: user普通用户。当启用network_mode: "host"时，容器共享宿主机的网络命名空间，SDK的C++二进制可能需要访问宿主机网络栈的敏感资源（如原始套接字、特定网络设备），这些操作普通用户默认无权限执行，root/sudo则可绕过限制，这是段错误的核心原因。

2. 环境配置不一致
   docker run命令中指定了-h $HOSTNAME（容器主机名与宿主机对齐），还挂载了/tmp/.X11-unix用于X11显示，但docker-compose.yml中缺少这两项配置。部分SDK依赖主机名解析或X11资源访问，普通用户在host网络模式下，缺失这些配置会触发权限相关的段错误。

3. 安全模块约束
   宿主机的SELinux或AppArmor安全模块，在host网络模式下对普通用户的容器进程施加了更严格的资源访问限制，阻止二进制执行必要操作，sudo运行时会跳过这些约束。

解决方案 #

方案1：对齐docker-compose与docker run的环境配置 #

修改docker-compose.yml，补充缺失的主机名设置和X11挂载，消除环境差异：

version: "3.9"
services:
    user_image:
        image: user_image:latest
        command: bash -c "roscore"
        container_name: my_stack
        user: user
        privileged: true
        stdin_open: true
        tty: true  # 和docker run的-it参数保持一致，启用终端交互
        network_mode: "host"
        environment:
            - DISPLAY=${DISPLAY}
        hostname: ${HOSTNAME}  # 对齐docker run的-h参数
        volumes:
            - /tmp/.X11-unix:/tmp/.X11-unix  # 挂载X11套接字

方案2：给二进制文件添加权限能力 #

如果SDK二进制需要特定网络权限，可在用户镜像构建时用setcap给二进制添加对应能力，让普通用户无需sudo即可运行：

# 替换为二进制在容器内的实际路径，权限能力根据SDK需求调整
RUN setcap cap_net_admin,cap_net_raw+ep /path/to/StViewer

方案3：调整安全模块规则（临时测试用） #

若为SELinux限制，可临时在宿主机执行：

setenforce 0

测试有效后，可添加永久规则：

semanage permissive -a container_t

对于AppArmor，可临时禁用对应容器的配置，或修改规则允许相关资源访问。

方案4：补充用户组权限 #

确认user用户是否加入所有必要系统组，比如SDK需访问USB设备时，添加到对应组：

RUN usermod -aG dialout,plugdev user

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