bug(podman): verify managed volume ownership before sandbox cleanup

[elezar]

User Story

While reviewing OpenShell PR #3981, I identified a gap in managed-volume cleanup. I need sandbox deletion to preserve Podman volumes that do not belong to the sandbox being deleted, including when the workload container is already absent.

This was identified during code review. No live data loss or runtime reproduction is claimed.

Problem Statement

The Podman driver checks ownership labels before adopting an existing managed volume during creation, but deletes managed workspace and channel volumes by their generated names without checking their ownership labels.

delete_sandbox attempts to remove openshell-channel-{sandbox_id} and openshell-sandbox-{sandbox_id}-workspace. The workspace removal also occurs when the workload-container lookup returns no container. PodmanClient::remove_volume validates the name and sends a DELETE request directly; it does not inspect the volume.

If an unused, unrelated volume occupies either generated name, sandbox cleanup can delete it despite missing or conflicting sandbox ownership labels. This gap predates #3981; the PR's UID/GID creation options do not introduce it.

Impact / Why This Matters

An unrelated volume that collides with a generated managed-volume name can lose its stored data during sandbox cleanup. Name uniqueness is currently the only deletion safeguard for these volumes. Operators would need to avoid collisions or manually verify names before cleanup; deletion itself does not enforce the ownership boundary already used during provisioning.

Acceptance Criteria

• Managed workspace and channel cleanup checks sandbox ownership labels before requesting volume deletion.
• Missing or mismatching ownership labels preserve the volume and produce a clear diagnostic.
• Correctly labeled managed volumes remain cleanable when the workload container is already absent.
• Missing volumes remain a successful, idempotent no-op.
• Filesystem UID/GID options are not required to match for deletion: legacy volumes with empty options and correctly labeled volumes with stale ownership settings remain cleanable.
• Regression coverage verifies that no DELETE request is issued for an unrelated same-name volume, both with and without a workload container.

Reproduction Steps / Proposed Validation

Runtime reproduction has not been performed. The following is a proposed OpenShell driver regression scenario, using the existing Podman API stub rather than installing additional tools:

1. Configure the OpenShell Podman driver's existing test fixture for a sandbox ID, with an unused workspace or channel volume at its generated managed-volume name. Give that volume no ownership labels, or an openshell.ai/sandbox-id label naming a different sandbox.
2. Arrange for the workload-container lookup to return no container.
3. Invoke the driver's delete_sandbox for that sandbox ID and capture its API requests.
4. The current implementation requests DELETE for the generated volume name without an inspect/ownership check. The expected behavior is to preserve the unrelated volume.
5. Repeat with a present workload container and with correctly labeled or missing managed volumes to verify preservation, ordinary cleanup, and idempotence.

Environment

• Reviewed PR: fix(podman): create managed workspace volumes owned by the workload identity #3981, head 53e7b71f1903584d0350465971f9a0663a1cac30.
• Confirmed on the PR base: 1b77cd4e931258d7e33beb486d202d1086d23dee.
• Deployment scope: OpenShell Podman compute driver; code inspection only. OS, Podman version, and live deployment behavior were not tested.

Agent Investigation

• Base delete_sandbox implementation removes managed volumes by generated names, including the no-workload-container path.
• Base client volume operations show creation ownership checks and direct deletion without inspection.
• The existing delete_sandbox_cleans_up_volume_when_container_is_already_gone test asserts the direct DELETE request; extend coverage with mismatched ownership metadata.
• A scoped implementation could retain low-level remove_volume and introduce remove_owned_volume(name, sandbox_id) or an equivalent managed-cleanup check. Ownership here means OpenShell resource labels, not filesystem UID/GID.
• Searched open and closed issues for Podman volume ownership, Podman volume deletion, and volume "unrelated". No matching issue was found. Related closed issue bug(driver-podman): per-sandbox secrets and volumes are orphaned when a container disappears without DeleteSandbox #2352 concerns orphaned resources when cleanup is not invoked; this issue concerns preserving unrelated resources when cleanup is invoked.

[aetherxeg-source]

A generated resource name should not itself confer deletion authority.

The invariant I would use is:

"name match != ownership proof"

For managed-volume cleanup, the deletion path should consume authoritative ownership evidence from the actual volume:

"resolved volume -> ownership labels -> expected sandbox identity/generation -> delete authorization"

A particularly important negative regression:

1. create unrelated volume V using the generated name expected for sandbox S;
2. give V missing or conflicting ownership metadata;
3. delete S;
4. verify no DELETE request for V is emitted.

Then repeat after the workload container is already absent.

This catches the dangerous case where loss of one piece of runtime state causes the cleanup path to fall back to weaker name-based authority.

Related reference implementation / design work: AETHER X GLOBAL ExecSurface — https://github.com/AETHERXGLOBAL/execsurface