fix(podman): create managed workspace volumes owned by the workload identity - #3932
Merged
matthewgrossman merged 0 commit intoSep 30, 2026
Conversation
|
Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually. Contributors can view more details about this message here. |
This was referenced Sep 30, 2026
matthewgrossman
added this pull request to stack #3936
September 30, 2026 06:06
4 tasks
Contributor
Author
|
/ok to test b6eabeb |
matthewgrossman
force-pushed
the
podman-workdir/b-volume-ownership
branch
from
September 30, 2026 08:48
b6eabeb to
0014abf
Compare
matthewgrossman
force-pushed
the
podman-workdir/b-volume-ownership
branch
from
September 30, 2026 18:33
0014abf to
e10d66f
Compare
7 of 8 tasks
This was referenced Sep 30, 2026
Contributor
Author
|
GitHub automatically marked this PR merged when its reordered head became an ancestor of its old base during stack maintenance. The change has not landed on main. Replacement draft PR: #3981, in the new stack #3983. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fix Podman sandboxes that cannot start when their image or policy selects a non-root user. Podman now creates the managed
/sandboxvolume for that user, so the workload can start and write there without first running as root.This is the second of three stacked PRs split out of #3801: #3931 ← this PR ← #3933. Review after #3931.
What breaks today, and why this fix
For example, build an image with
USER 2345:2346and no/sandbox, or use a USER-less image with policyrun_as_user: "2345"andrun_as_group: "2346". On a rootful Podman gateway, OpenShell gives the workload a managed/sandboxvolume, but Podman creates its root asroot:rootwith mode0700. User 2345 cannot enter it, so sandbox provisioning fails before the agent command can run (locally,ContainerExited ... code 1; the entrypoint can reportPermission denied). The user cannot fix this from inside the sandbox because the process has no authority to change the directory's ownership.Docker already prepares its managed
/sandboxdirectory owned by the workload UID/GID before starting the capability-free process: it stages a directory in the container archive with those ownership and permission settings. Podman uses a named volume instead of that Docker archive directory. We could start Podman's workload as root, adjust/sandboxownership/permissions, then drop to the requested user—as the old root-then-drop path did for some launches—but that adds a privileged setup step to every affected start. Instead, this PR passes the final UID/GID directly to Podman when creating the volume. Podman makes the volume root owned by that user, and the workload starts as that user from the outset with no added capabilities. The channel volume remains unchanged.Related Issue
Fixes #3937. This bug was found while working on #3801 / #2526: the shared
oci-imagesuite'sdefault_workdir_uses_managed_workspacescenario exposed it on rootful Podman. Docker already gives the image user a writable/sandbox.Changes
client.rs:create_owned_volume(..., owner: Option<(u32, u32)>)sendsOptions: {"o": "uid=…,gid=…"}and verifies the created or existing volume against a sharedvolume_options_match_ownerpredicate. Podman records the parsedUID/GIDnext too. AddContainerConfig.userfor admission.driver.rs: create the workspace volume owned by(identity.uid, identity.gid)and the channel volume with no options. Resource admission accepts a workspace volume whose options match the container's numericConfig.User, or have no options (created by older gateways). The channel volume still requires empty options. Remove the now-unusedrootlessdriver field.container.rs: remove thelaunch-capability-freeroot-then-drop branch andIsolationSpecInput.rootless. The workload always runs--bootstrapas the final identity withcap_drop: ALLand no added capabilities.launch-capability-freestays inopenshell-sandboxbecause the VM driver still uses it.e2e/rust/tests/podman_oci_identity.rs: the workload container user is now{OCI_UID}:{OCI_GID}instead of0:0.Testing
All checks ran against a local rootful Podman machine (macOS, libkrun).
mise run pre-commitpassescargo test -p openshell-driver-podman --lib(228 passed), with newcreate_owned_volume_verifies_requested_ownerandadmission_accepts_workspace_volume_owned_by_workload_identity, and updated isolation-spec tests.cargo clippy -p openshell-driver-podman --all-targets -- -D warningsis clean.podman_oci_identitypasses.e2e/with-podman-gateway.sh. Each case runsid; stat /sandbox; touch /sandbox/probe:ubuntu:24.04with policyrun_as_user: "2345",run_as_group: "2346": onmain, provisioning fails withContainerExited ... code 1. With this PR it runs as2345:2346,/sandboxis2345:2346 700, and the write succeeds.USER 2345:2346and no/sandbox: same results onmainand with this PR.resource_admission.enabled = truetemporarily set ine2e/support/podman-gateway-config.sh(not committed),oci-image'sdefault_workdir_uses_managed_workspacepasses. With the owner-match branch of the admission check disabled, it fails withsandbox lacks attachment provenance.Checklist