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.

[jiridanek]

I had the same problem in

opendatahub-io/notebooks here (lines 20 to 29)

and opendatahub-io/notebooks here lines 114 to 126

 # Workaround: ubuntu-26.04 AppArmor stub profile for podman gives it a named label
 # ("podman") instead of "unconfined". The pasta profile only allows signals from
 # "unconfined" (via abstractions/base), so podman can't SIGTERM pasta on container
 # stop → "rootless netns: kill network process: permission denied".
 # Fix: allow pasta to receive signals from the podman profile.
 # https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1100135
 - name: Fix AppArmor pasta/podman signal conflict
 run: |
 set -Eeuxo pipefail
 if [[ -f /etc/apparmor.d/abstractions/pasta ]] && ! grep -q 'peer=podman' /etc/apparmor.d/abstractions/pasta; then
 echo ' signal (receive) peer=podman,' | sudo tee -a /etc/apparmor.d/abstractions/pasta
 sudo apparmor_parser -r /etc/apparmor.d/usr.bin.pasta
 fi

The solution suggested in the issue is better in that it explicitly sets a signal mask.

edit: for sure more targetted, not certain if better, in case some additional signal besides term need to be delivered. I did not found any evidence it sends anything besides signal 15 and 0 (already allowed).

The ubuntu bug https://bugs.launchpad.net/ubuntu/+source/passt/+bug/2154379 proposes a patch adding blanket allow for all signals, without restricted set.

[elezar]

📋 triage-agent

Triage Assessment

Classification: validated-bug

Summary

The rootless Podman E2E environment on Ubuntu 26.04 is degraded by an AppArmor policy that prevents Podman from delivering SIGTERM to pasta. This is a CI runner/workflow configuration defect, rather than a defect in the OpenShell Podman driver. The report is complete and the impact and workaround are credible.

Investigation

The rootless E2E workflow intentionally runs directly on the Ubuntu host, pins Podman 5.7.0 and conmon 2.1.13, requires the pasta network helper and AppArmor enforcement, and currently only prints AppArmor denials after the test. It contains no profile remediation.

The cited failed rootless E2E job for PR #2370 recorded repeated 15-second SIGTERM stop failures followed by SIGKILL and the exact profile="pasta" ... comm="podman" ... requested_mask="receive" denied_mask="receive" signal=term peer="podman" denial. PR #2744 also has a failed rootless E2E job. PR #2822 passed but still logged matching pasta denials, establishing flakiness rather than a fix. No OpenShell duplicate was found; #2855, #2540, #2215, and closed #1194 are related but distinct.

The proposed targeted rule is feasible to test in the workflow if the job can reload the profile with sudo. Preserve the test intent by keeping AppArmor enforcing and allowing only the required pasta receive signal. The implementation should establish whether the runner image, Ubuntu package, or runner provisioning owns the profile, and verify whether any signals beyond TERM are needed.

Impact Signals

• Affected users/scope: Contributors and maintainers using the Ubuntu 26.04 rootless Podman E2E lane; not evidence of an end-user runtime defect.
• Regression: Unknown; the current workflow provides no baseline before the Ubuntu 26.04/pasta profile behavior.
• Workaround: Re-running CI can mask timing but does not remove the deterministic denial or 15-second fallback delay.
• Evidence quality: High for the policy denial and delayed stop behavior, based on public CI logs; medium for the causal effect on each individual cited test failure.

Follow-up Evidence

After a targeted runner-profile change, verify the loaded profile, prompt podman stop behavior, absence of matching dmesg denials, and multiple consecutive rootless E2E runs. Acceptance criterion 2 should use repeated runs and a stop-time bound rather than one successful rerun. Note that SIGKILL fallback is not graceful termination.

Human Decision Required

Decide whether OpenShell should address this issue. If yes, apply state:accepted, associate it with a roadmap item, or do both, and decide whether the work remains human-owned. Either action records acceptance; roadmap placement additionally records sequencing.
To queue investigation or planning for an unattended agent, also apply agent:plan-requested. You can instead directly ask an agent to use create-spike or build-from-issue on this issue. If no, close it as not planned and record the rationale.