Skip to content

Adopt OpenShell runtime UID/GID support in policies and container images #100

Closed

Description

@guyoron1

Mirrored from fullsend-ai/fullsend#2916 — costwise baseline tracking

What happens: All 6 fullsend policy files hardcode run_as_user: sandbox and run_as_group: sandbox, and container images bake in a sandbox user at UID 1000660000 via groupadd/useradd in the Dockerfile. This ties fullsend to a specific container image convention that OpenShell is moving away from.

What should happen: Once OpenShell supports runtime UID/GID injection, fullsend should:

  • Update policy files to accept driver-provided numeric UIDs instead of hardcoding the sandbox user name
  • Remove the groupadd/useradd lines from container image Dockerfiles that create the sandbox user at a fixed UID
  • Verify that safe-push Landlock paths and filesystem ownership still work with runtime-assigned UIDs

Affected policy files:

  • policies/code.yaml
  • policies/fix.yaml
  • policies/review.yaml
  • policies/retro.yaml
  • policies/triage.yaml
  • policies/prioritize.yaml

Context: OpenShell is decoupling sandbox user identity from container images. NVIDIA/OpenShell#1959 tracks the design, and NVIDIA/OpenShell#1973 implements numeric UID acceptance in the policy engine and supervisor. That PR is still WIP.

This is a nice-to-have cleanup — existing images and policies continue to work after the OpenShell change lands. The main benefit is simpler images and alignment with where OpenShell is heading. It also unblocks future compatibility with platforms that assign their own UIDs at runtime (e.g., OpenShift SCCs).

Blocked on: NVIDIA/OpenShell#1973 merging and shipping in a release.

Activity

  1. guyoron1 commented on Jul 6, 2026

    @guyoron1
    OwnerAuthor

    /fs-triage

  2. fullsend-ai-triage commented on Jul 6, 2026

    @fullsend-ai-triage

    🤖 Finished Triage · ✅ Success · Started 2:06 PM UTC · Completed 2:10 PM UTC
    Commit: a9ab22d · View workflow run →

  3. fullsend-ai-triage commented on Jul 6, 2026

    @fullsend-ai-triage

    Triage Summary (re-triage)

    Severity: Low · Category: Feature (cleanup/alignment)

    Problem

    All 6 fullsend policy files hardcode run_as_user: sandbox / run_as_group: sandbox, and container Dockerfiles bake in a sandbox user at a fixed UID. This ties fullsend to a container image convention that OpenShell is moving away from.

    Upstream Dependency — Resolved ✅

    The blocker identified in this issue (NVIDIA/OpenShell#1973) has been merged (2026-07-02) and shipped in OpenShell v0.0.76. The OpenShell policy engine and supervisor now accept numeric UIDs in the range [1000, 2,000,000,000] for run_as_user/run_as_group. The broader design issue (NVIDIA/OpenShell#1959) remains open but does not block this work — the specific policy engine change has already landed.

    This issue is unblocked and ready for implementation.

    Recommended Approach

    1. Update the 6 policy files (code.yaml, fix.yaml, review.yaml, retro.yaml, triage.yaml, prioritize.yaml) to use driver-provided numeric UIDs instead of the hardcoded sandbox string
    2. Remove groupadd/useradd lines from container image Dockerfiles
    3. Verify Landlock safe-push paths and filesystem ownership work with runtime-assigned UIDs
    4. Confirm OpenShell >= v0.0.76 as the minimum version requirement

    Proposed Test Case

    - Policy files with numeric run_as_user/run_as_group values (e.g., 1000660000)
      are parsed and enforced correctly by the OpenShell policy engine
    - Container images without a baked-in sandbox user launch successfully
      with runtime-injected numeric UIDs
    - Landlock safe-push paths and chown-based filesystem ownership work
      with the runtime-assigned UID
    - Edge cases: UID 0 and UIDs < 1000 are rejected by policy validation;
      string 'sandbox' still works as backward-compatible fallback if needed
    

    Impact

    This is a nice-to-have cleanup. Existing images and policies continue to work. Benefits include simpler container images, alignment with OpenShell's direction, and future compatibility with platforms that assign UIDs at runtime (e.g., OpenShift SCCs).

    Previous run

    Triage Summary

    Severity: Low · Category: Feature (cleanup/alignment)

    Problem

    All 6 fullsend policy files hardcode run_as_user: sandbox / run_as_group: sandbox, and container Dockerfiles bake in a sandbox user at a fixed UID. This ties fullsend to a container image convention that OpenShell is moving away from.

    Upstream Dependency — Resolved ✅

    The blocker identified in this issue (NVIDIA/OpenShell#1973) has been merged and shipped in OpenShell v0.0.76 (released 2026-07-03). The OpenShell policy engine and supervisor now accept numeric UIDs in the range [1000, 2,000,000,000] for run_as_user/run_as_group. This issue is unblocked and ready for implementation.

    Recommended Approach

    1. Update the 6 policy files (code.yaml, fix.yaml, review.yaml, retro.yaml, triage.yaml, prioritize.yaml) to use driver-provided numeric UIDs
    2. Remove groupadd/useradd lines from container image Dockerfiles
    3. Verify Landlock paths and filesystem ownership work with runtime-assigned UIDs

    Proposed Test Case

    - Verify policy files with numeric UIDs (e.g., run_as_user: '1000660000') are
      accepted by the OpenShell policy engine
    - Verify container images without a baked-in sandbox user launch successfully
      with runtime-injected numeric UIDs
    - Verify Landlock paths and chown-based filesystem ownership work with the
      runtime-assigned UID
    - Edge cases: UID 0 and UIDs < 1000 are rejected; string 'sandbox' still
      works as a backward-compatible fallback
    

    Impact

    This is a nice-to-have cleanup. Existing images and policies continue to work. Benefits include simpler container images, alignment with OpenShell's direction, and future compatibility with platforms that assign UIDs at runtime (e.g., OpenShift SCCs).


    Labels: This is an enhancement/feature request for adopting upstream OpenShell changes. Labeled as 'enhancement' based on its nature as a forward-looking alignment change.

  4. guyoron1 commented on Jul 6, 2026

    @guyoron1
    OwnerAuthor

    /fs-triage

  5. fullsend-ai-triage commented on Jul 6, 2026

    @fullsend-ai-triage

    🤖 Finished Triage · ✅ Success · Started 4:24 PM UTC · Completed 4:28 PM UTC
    Commit: 6a1b34d · View workflow run →

  6. guyoron1 commented on Jul 6, 2026

    @guyoron1
    OwnerAuthor

    /fs-triage

  7. guyoron1 commented on Jul 6, 2026

    @guyoron1
    OwnerAuthor

    /fs-triage

  8. github-actions commented on Jul 6, 2026

    @github-actions

    Triage Summary (re-triage)

    Severity: Low · Category: Feature (cleanup/alignment)

    Problem

    All 6 fullsend policy files hardcode run_as_user: sandbox / run_as_group: sandbox, and container Dockerfiles bake in a sandbox user at a fixed UID. This ties fullsend to a container image convention that OpenShell is moving away from.

    Upstream Dependency — Resolved ✅

    The blocker identified in this issue (NVIDIA/OpenShell#1973) has been merged (2026-07-02) and shipped in OpenShell v0.0.76. The OpenShell policy engine and supervisor now accept numeric UIDs in the range [1000, 2,000,000,000] for run_as_user/run_as_group. The broader design issue (NVIDIA/OpenShell#1959) remains open but does not block this work — the specific policy engine change has already landed.

    This issue is unblocked and ready for implementation.

    Recommended Approach

    1. Update the 6 policy files (code.yaml, fix.yaml, review.yaml, retro.yaml, triage.yaml, prioritize.yaml) to use driver-provided numeric UIDs instead of the hardcoded sandbox string
    2. Remove groupadd/useradd lines from container image Dockerfiles
    3. Verify Landlock safe-push paths and filesystem ownership work with runtime-assigned UIDs
    4. Document OpenShell >= v0.0.76 as the minimum version requirement

    Proposed Test Case

    - Policy files with numeric run_as_user/run_as_group values (e.g., 1000660000)
      are parsed and enforced correctly by the OpenShell policy engine
    - Container images without a baked-in sandbox user launch successfully
      with runtime-injected numeric UIDs
    - Landlock safe-push paths and chown-based filesystem ownership work
      with the runtime-assigned UID
    - Edge cases: UID 0 and UIDs < 1000 are rejected by policy validation;
      string 'sandbox' still works as backward-compatible fallback if needed
    

    Impact

    This is a nice-to-have cleanup. Existing images and policies continue to work. Benefits include simpler container images, alignment with OpenShell's direction, and future compatibility with platforms that assign UIDs at runtime (e.g., OpenShift SCCs).

    Previous runs

    Triage Summary (run 3)

    Upstream dependency (NVIDIA/OpenShell#1973) confirmed merged (2026-07-02), shipped in OpenShell v0.0.76. Issue unblocked and ready for implementation. Same recommended approach and test cases as prior runs.


    Triage Summary (run 2)

    Upstream dependency confirmed merged and shipped. Recommended approach unchanged.


    Triage Summary (run 1)

    Initial triage identified upstream dependency on NVIDIA/OpenShell#1973 as resolved. Recommended updating 6 policy files, removing Dockerfile user creation, and verifying Landlock paths with runtime UIDs.

    Previous run

    Triage Summary (re-triage)

    Severity: Low · Category: Feature (cleanup/alignment)

    Problem

    All 6 fullsend policy files hardcode run_as_user: sandbox / run_as_group: sandbox, and container Dockerfiles bake in a sandbox user at a fixed UID. This ties fullsend to a container image convention that OpenShell is moving away from.

    Upstream Dependency — Resolved ✅

    The blocker identified in this issue (NVIDIA/OpenShell#1973) has been merged (2026-07-02) and shipped in OpenShell v0.0.76. The OpenShell policy engine and supervisor now accept numeric UIDs in the range [1000, 2,000,000,000] for run_as_user/run_as_group. The broader design issue (NVIDIA/OpenShell#1959) remains open but does not block this work — the specific policy engine change has already landed.

    This issue is unblocked and ready for implementation.

    Recommended Approach

    1. Update the 6 policy files (code.yaml, fix.yaml, review.yaml, retro.yaml, triage.yaml, prioritize.yaml) to use driver-provided numeric UIDs instead of the hardcoded sandbox string
    2. Remove groupadd/useradd lines from container image Dockerfiles
    3. Verify Landlock safe-push paths and filesystem ownership work with runtime-assigned UIDs
    4. Confirm OpenShell >= v0.0.76 as the minimum version requirement

    Proposed Test Case

    - Policy files with numeric run_as_user/run_as_group values (e.g., 1000660000)
      are parsed and enforced correctly by the OpenShell policy engine
    - Container images without a baked-in sandbox user launch successfully
      with runtime-injected numeric UIDs
    - Landlock safe-push paths and chown-based filesystem ownership work
      with the runtime-assigned UID
    - Edge cases: UID 0 and UIDs < 1000 are rejected by policy validation;
      string 'sandbox' still works as backward-compatible fallback if needed
    

    Impact

    This is a nice-to-have cleanup. Existing images and policies continue to work. Benefits include simpler container images, alignment with OpenShell's direction, and future compatibility with platforms that assign UIDs at runtime (e.g., OpenShift SCCs).

    Previous run (2)

    Triage Summary (run 2)

    Severity: Low · Category: Feature (cleanup/alignment)

    Upstream dependency (NVIDIA/OpenShell#1973) confirmed merged (2026-07-02), shipped in OpenShell v0.0.76. Issue unblocked and ready for implementation. Same recommended approach and test cases as initial triage.


    Triage Summary (run 1)

    Initial triage identified upstream dependency on NVIDIA/OpenShell#1973 as resolved. Recommended updating 6 policy files, removing Dockerfile user creation, and verifying Landlock paths with runtime UIDs.

  9. guyoron1 commented on Jul 7, 2026

    @guyoron1
    OwnerAuthor

    /fs-triage

  10. guyoron1 commented on Jul 7, 2026

    @guyoron1
    OwnerAuthor

    /fs-triage

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions