无root容器内使用Podman-Compose遇权限错误及最佳实践咨询

问题背景 #

我在项目中尝试在容器内运行Podman（即Podman in Podman），基础镜像试过Fedora和UBI9。为了符合代码规范，容器内不使用root用户，在Dockerfile末尾创建了podmanuser用户，但执行Podman时出现以下错误：

ERRO[0000] running /usr/bin/newuidmap 26 0 1000 1 1 100000 65536: newuidmap: write to uid_map failed: Operation not permitted
Error: cannot set up namespace using "/usr/bin/newuidmap": exit status 1

当前使用的Dockerfile内容如下：

FROM fedora:latest

# Install necessary packages
RUN dnf install -y \
    podman \
    python3 \
    python3-pip \
    sudo \
    && dnf clean all

# Install podman-compose
RUN pip3 install podman-compose

# Create storage directories
RUN mkdir -p /var/lib/containers/storage /tmp/containers

RUN echo "podmanuser:100000:65536" >> /etc/subuid && \
    echo "podmanuser:100000:65536" >> /etc/subgid

RUN useradd -m podmanuser

RUN chown root:root /usr/bin/newuidmap /usr/bin/newgidmap && \
    chmod 4755 /usr/bin/newuidmap /usr/bin/newgidmap

RUN mkdir -p /home/podmanuser/.config && chown -R podmanuser:podmanuser /home/podmanuser/.config

USER podmanuser

WORKDIR /podmanuser

CMD ["bash"]

疑问 #

1. 容器内避免使用root是否属于最佳实践？
2. Podman/Podman Compose运行失败，若需要在容器内使用DNF或chmod这类需要特权的工具，该如何处理？

解答 #

1. 容器内非root用户是否为最佳实践？ #

是的，这是容器安全领域的核心最佳实践之一。使用非root用户能大幅降低容器被攻破后，攻击者获取主机系统权限的风险，避免因容器内root权限泄露导致的主机资源篡改、数据泄露等问题。绝大多数生产环境的容器规范都要求以非root用户运行应用，这也是OCI容器标准推荐的安全实践。

2. 解决Podman in Podman的运行错误 #

你遇到的newuidmap权限问题，本质是容器缺乏用户命名空间的修改权限。要让非root用户在容器内运行Podman，启动容器时需要添加特定的命名空间映射参数（比直接用--privileged更安全）：

podman run -it --rm \
  --security-opt label=disable \
  --security-opt unshare=pid \
  --uidmap 1000:0:1 \
  --uidmap 0:1:1000 \
  --uidmap 1001:1001:64536 \
  --gidmap 1000:0:1 \
  --gidmap 0:1:1000 \
  --gidmap 1001:1001:64536 \
  your-image-name

这些参数会正确配置用户命名空间映射，让容器内的podmanuser拥有足够权限操作子容器的uid/gid映射。

3. 容器内使用特权工具的处理方式 #

如果需要在容器内使用DNF、chmod这类需要root权限的工具，有几种可行方案：

• 配置sudo权限：在Dockerfile中添加podmanuser的sudo规则，允许其无需密码执行特定特权命令：

  RUN echo "podmanuser ALL=(ALL) NOPASSWD: /usr/bin/dnf, /usr/bin/chmod" >> /etc/sudoers.d/podmanuser
  

  之后在容器内可以通过sudo dnf install xxx或sudo chmod xxx执行操作。
• 构建阶段用root，运行阶段切非root：将需要特权的操作（如安装依赖、修改文件权限）放在Dockerfile的USER root阶段完成，最后切换回非root用户运行应用。这种方式能避免运行时的特权风险。
• 最小化特权授予：不直接使用--privileged启动容器，而是通过--cap-add添加所需的特定能力（比如修改文件权限用CAP_CHOWN），但这种方式需要精准匹配权限，复杂度较高。

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