非root运行容器需三步闭环：构建阶段创建固定UID（如1001）用户、COPY时用--chown同步设文件归属、USER指令置于所有root操作之后；运行后须验证进程UID、root拒绝进入及越权操作失败。

默认情况下，Docker 容器内进程以 root 用户身份运行，这带来明显安全风险。要实现非 root 权限启动，关键不是“禁用 root”，而是主动指定一个权限最小、UID 固定的普通用户，并在构建和运行两个阶段协同控制。

在 Dockerfile 中创建并切换用户

这是最根本、最推荐的方式——把用户定义固化进镜像：

• 使用固定 UID（如 1001）创建用户，避免与宿主机 UID 冲突： Alpine/CentOS 系：RUN addgroup -g 1001 -f appgroup && adduser -S -u 1001 -G appgroup appuser Debian/Ubuntu 系：RUN adduser --disabled-password --gecos '' --uid 1001 appuser
• COPY 文件时同步设置归属：COPY --chown=1001:1001 . /app，确保代码、配置、日志目录对目标用户可读写
• USER 指令必须放在所有需要 root 的操作之后（如 apt 安装、编译），否则 RUN 会失败；正确顺序示例：
  RUN apt-get update && apt-get install -y curl
COPY --chown=1001:1001 . /app
USER 1001:1001
CMD ["./start.sh"]

在 docker-compose.yml 中显式声明用户

即使镜像中已设 USER，仍建议在 Compose 中再次明确指定，增强可读性与运行时约束：

OpenClaw Docker Setup

在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...

下载

• 用 UID:GID 形式（如 "1001:1001"）比用户名更可靠，不依赖容器内 /etc/passwd 解析
• 写法示例：
  services:
  web:
    image: myapp:latest
    user: "1001:1001"
• 若需临时调试，可用 docker exec -u 1001 -it container-name sh 验证是否生效

运行时补充加固（非必需但强烈建议）

仅靠 USER 不足以覆盖全部风险，可叠加以下选项提升纵深防御：

• --read-only：使根文件系统只读，防止恶意篡改二进制或配置
• --cap-drop=ALL --cap-add=NET_BIND_SERVICE：关闭全部 Linux capabilities，再按需开放（如绑定端口）
• --security-opt no-new-privileges：禁止进程通过 setuid/setgid 提权
• 若监听 80 端口，应用层改用 8080，由反向代理（如 Nginx）做端口转发

验证是否真正生效

不能只看 Dockerfile 写了 USER 就认为完成。启动后务必检查：

• 进容器执行 ps aux | grep your-app，确认 USER 列显示为 1001 或对应用户名
• 尝试以 root 进入：docker exec -u 0 -it container-name sh，应被拒绝（除非启用 user namespace remap）
• 测试越权操作：docker exec -u 1001 container-name touch /etc/test，应返回 Permission denied