ci: AppArmor profile blocks pasta from receiving SIGTERM on ubuntu-26.04 runners, failing rootless E2E

[politerealism]

User Story

As an OpenShell contributor, I need the ubuntu-26.04 E2E runner to correctly support rootless Podman container lifecycle so that CI results reflect code correctness rather than runner configuration.

Problem Statement

The pasta AppArmor profile on the ubuntu-26.04 GitHub Actions runners does not permit Podman to send SIGTERM to pasta. This causes every rootless Podman container stop to fail gracefully and fall back to SIGKILL after a 15-second timeout. Depending on test timing, this causes various tests in the E2E (rust-podman-rootless, ubuntu-26.04) job to fail with unrelated-looking errors.

The AppArmor denial appears in dmesg on every affected run:

apparmor="DENIED" operation="signal" class="signal"
profile="pasta" comm="podman"
requested_mask="receive" denied_mask="receive" signal=term peer="podman"

Impact / Why This Matters

Consequences of current behavior:

• Every container stop in the rootless Podman E2E job hangs for 15 seconds waiting for SIGTERM to take effect, then falls back to SIGKILL
• Tests that depend on clean container lifecycle (graceful shutdown, file uploads, sandbox teardown) fail non-deterministically depending on whether the 15s SIGKILL delay crosses a test timeout boundary
• Different tests fail on different PRs: podman_userns_keep_id (PR fix(sandbox): terminate sandbox when proxy accept loop exits unexpectedly #2370), upload_gitignored_directory_falls_back_to_unfiltered (PR refactor(compute): support external driver parity #2744) — same root cause, different symptom

Current workaround: Re-running CI. This is insufficient because the AppArmor denial is deterministic per runner image — the SIGKILL fallback always occurs, it just doesn't always cross a test timeout on every run.

PRs confirmed affected today (2026-08-20): #2370, #2744, and likely #2822.

Acceptance Criteria

• The pasta AppArmor profile on ubuntu-26.04 runners allows Podman to send SIGTERM to pasta (signal receive peer=podman rule added)
• E2E (rust-podman-rootless, ubuntu-26.04) passes consistently on a re-run of an affected PR
• No apparmor="DENIED" ... profile="pasta" ... signal=term lines appear in dmesg during E2E runs

Reproduction Steps

1. Open any PR that touches sandbox or Podman driver code
2. Wait for Branch E2E Checks → E2E (rust-podman-rootless, ubuntu-26.04) to complete
3. If it fails, check the AppArmor step at the end of the job log:

   sudo dmesg | grep -E 'apparmor=.*DENIED|profile="unprivileged_userns"'
   

4. Observe repeated denials of the form:

   apparmor="DENIED" operation="signal" profile="pasta"
   requested_mask="receive" denied_mask="receive" signal=term peer="podman"
   

Environment

• Runner: ubuntu-26.04 (NVIDIA managed runners, nv-cpu-ubuntu-26.04 pool)
• Podman: 5.x (rootless mode)
• pasta: version on the runner image
• AppArmor status: enforcing

Suggested Fix

The pasta AppArmor profile needs a rule permitting Podman to deliver SIGTERM:

signal receive set=(term) peer=podman,

This is the upstream pasta AppArmor fix for rootless Podman integration. The ubuntu-26.04 runner image may be shipping a pasta AppArmor profile that predates this rule being merged, or the rule may need to be added to the runner provisioning scripts.