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
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions