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
Reproduction Steps
- 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".
- Create a sandbox from the image without a custom
WORKDIR.
- 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.
User Story
As a sandbox user, I want a non-root image user or policy-selected identity to write to the managed
/sandboxworkspace on Podman, so that my workload starts and can persist files there.Problem Statement
On rootful Podman, an image with a non-root
USERor a policy with a non-rootrun_as_usercan fail to start when using the default managed/sandboxworkspace. Its named volume root isroot: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
/sandboxon 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
USERcan start and write to the managed/sandboxworkspace.run_as_userandrun_as_groupcan do the same.Reproduction Steps
ubuntu:24.04withUSER 2345:2346and no/sandboxdirectory, or use a USER-lessubuntu:24.04image with policyrun_as_user: "2345"andrun_as_group: "2346".WORKDIR.id; stat /sandbox; touch /sandbox/probein the sandbox. Provisioning fails on main withContainerExited ... code 1; with the fix,/sandboxis owned by2345:2346with mode0700and the write succeeds.Environment
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
WORKDIRsupport. The precisePermission deniedmessage was not captured in the manual baseline repro; the observed baseline outcome was a container exit with code 1.