bug: rootful Podman managed workspace is unwritable for non-root workloads #3937

User Story

As a sandbox user, I want a non-root image user or policy-selected identity to write to the managed /sandbox workspace on Podman, so that my workload starts and can persist files there.

Problem Statement

On rootful Podman, an image with a non-root USER or a policy with a non-root run_as_user can fail to start when using the default managed /sandbox workspace. Its named volume root is root:root 0700, inaccessible to the workload identity. On the current main branch, the rootless/default-identity launch path also starts as container root to change workspace ownership before dropping privileges.

Impact / Why This Matters

Non-root workloads cannot reliably start or write to /sandbox on rootful Podman. Users can alter images or run as root to work around it, but that either requires changing the image and runtime workflow or weakens the intended least-privilege boundary. Docker already supports the corresponding non-root workspace flow.

Acceptance Criteria

• A rootful Podman sandbox using a non-root image USER can start and write to the managed /sandbox workspace.
• A rootful Podman sandbox using a non-root policy run_as_user and run_as_group can do the same.
• The workload starts directly as its resolved identity without a temporary root/chown launch step.
• Resource admission accepts driver-created workspace ownership metadata while still rejecting unexpected options and requiring the control-channel volume to have no options.

Reproduction Steps

1. On a rootful Podman gateway using the main branch, build an image based on ubuntu:24.04 with USER 2345:2346 and no /sandbox directory, or use a USER-less ubuntu:24.04 image with policy run_as_user: "2345" and run_as_group: "2346".
2. Create a sandbox from the image without a custom WORKDIR.
3. Try to run id; stat /sandbox; touch /sandbox/probe in the sandbox. Provisioning fails on main with ContainerExited ... code 1; with the fix, /sandbox is owned by 2345:2346 with mode 0700 and the write succeeds.

Environment

• OpenShell: main before the Podman workspace ownership fix
• Host: macOS with a rootful Podman machine (libkrun)
• Runtime: Podman compute driver

Investigation

Found while adding the shared OCI image tests for #2526. The standalone fix is proposed in #3932, stacked after #3931; #3933 builds on it for custom OCI WORKDIR support. The precise Permission denied message was not captured in the manual baseline repro; the observed baseline outcome was a container exit with code 1.