Skip to content

Request: support non-root user execution in Docker container #931

@byongwu

Description

@byongwu

Summary

The current openpi project does not specify a USER directive in Docker-based deployments, causing container processes to run as root. Community integrations that build on openpi inherit this pattern. This is flagged by container security scanners (Semgrep, Checkov CKV_DOCKER_8) and is a security anti-pattern.

Current behavior

When building a Docker image based on nvcr.io/nvidia/cuda:12.3.2-cudnn9-devel-ubuntu22.04 + openpi:

  • uv is installed to /root/.local/bin via curl -LsSf https://astral.sh/uv/install.sh | sh
  • PATH="/root/.local/bin:$PATH" hardcodes a root-only path
  • No USER directive → all container processes run as root

Desired behavior

Container process should run as a non-root user (e.g., appuser) while retaining full GPU / CUDA and JAX access.

Why this is blocked today

  1. uv installation path: uv installs to /root/.local/bin by default. Switching to a non-root user requires reinstalling uv to a shared path (e.g., /usr/local/bin) or updating PATH.
  2. Model checkpoint directory: /opt/pi-cache and checkpoint files are written as root during the build phase; need chown before the USER switch.
  3. JAX CUDA initialization: Uncertain whether JAX GPU initialization requires root privileges inside NVIDIA CUDA base images.

Proposed approach

# Install uv to a shared location accessible to non-root
RUN curl -LsSf https://astral.sh/uv/install.sh | env UV_INSTALL_DIR=/usr/local/bin sh

# After all setup steps:
RUN useradd -m -u 1000 appuser && \
    chown -R appuser:appuser /opt/pi-cache /opt/openpi /opt/ml

USER appuser

Question: Is there a known blocker for non-root execution with nvcr.io/nvidia/cuda base images for JAX workloads? Does JAX GPU (CUDA) initialization require root, or can it run as a non-privileged user?

Security context

Running containers as root is considered a security anti-pattern, especially for:

  • Open-source projects intended for research/production use
  • Environments with Kubernetes/ECS runtime security policies (e.g., runAsNonRoot: true)
  • Security reviews (e.g., AWS PCSR / AppSec) that flag CKV_DOCKER_8 / SEC-001

Any guidance on the safest path to non-root execution would be greatly appreciated.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions