Reject conflicting VM user requests and report the identity that runs the workload

[shiju-nv]

User Story

As an operator setting a sandbox's user and group, I want OpenShell to report the identity that actually runs my code and reject incompatible requests, so that I can reason about workspace ownership and permissions.

Problem Statement

The local v0.1.2 VM accepted a process policy requesting user/group 10000:10000 and reported that policy as effective, while canonical and exec processes ran as the driver's resolved 1000:1000. VM identity is deliberately driver-owned, but the accepted policy did not make the conflict visible.

Impact / Why This Matters

Users can investigate file-access and ownership failures using an effective-policy value that does not match execution. They may believe a user selection was applied when the runtime preserved its different driver identity.

Acceptance Criteria

• A request for 10000:10000 against a driver resolving 1000:1000 fails before the workload starts and names both identities.
• Matching numeric or symbolic requests reach Ready and canonical/exec processes report the displayed identity.
• Independent user and group mismatches are detected; omitted selectors use the documented default.
• Restarted overlays preserve their existing ownership, and a conflicting policy cannot silently change it.
• Policy and runtime documentation describe the same driver-owned identity behavior.

Reproduction Steps

1. Use the v0.1.2 VM driver with an image/configuration that resolves its sandbox account to 1000:1000.
2. In the process section of an otherwise valid policy, set run_as_user and run_as_group to "10000".
3. Inspect the stored policy and its reported effective status.
4. Run id -u and id -g through sandbox exec and compare the result with the policy selectors. The recorded result was 1000:1000.

Environment

• OpenShell: v0.1.2; current-source comparison at b8ffe5244cb244a1d74a4a03d69afe3da07e5f08.
• Platform: Apple Silicon macOS 26.7; MicroVM backend.
• Installation: released CLI, gateway and VM driver

Logs

[purp]

📋 triage-agent

Triage Assessment

Classification: validated-bug

Summary

Reproduced on v0.1.2 with high confidence. A policy that requests run_as_user/run_as_group: "10000" is stored and reported as Status: Effective. Both the entrypoint and sandbox exec still run as the driver-resolved 1000:1000, and nothing reports the conflict.

Investigation

Setup: v0.1.2 release binaries, MicroVM, nvcr.io/nvidia/base/ubuntu:24.04 (whose image account resolves to ubuntu 1000:1000), Apple Silicon (macOS 26.7).

• With --policy setting process.run_as_user/run_as_group: "10000", the entrypoint id prints uid=1000(ubuntu) gid=1000(ubuntu).
• openshell policy get shows Status: Effective and run_as_user: "10000".
• sandbox exec -- id -u/-g returns 1000:1000.
• On main, the driver owns the UID/GID (crates/openshell-driver-vm/src/driver.rs:407-413; openshell-vm-sandbox-init.sh:88-104). The supervisor overwrites the policy's run_as_user/run_as_group without comparing them (crates/openshell-sandbox/src/identity.rs:97-99).

Impact Signals

• Affected users/scope: VM sandboxes whose policy requests an identity different from the driver's resolved account.
• Regression: unknown
• Workaround: set sandbox_uid/sandbox_gid on the driver, or match the policy to the image account. Nothing surfaces the mismatch.
• Evidence quality: high: live reproduction plus code path.

Disposition

Accepted by @purp on 2026-09-30 as part of the #3955 macOS MicroVM review.