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

Activity

1. github-actions

   added

   state:triage-neededOpened without agent diagnostics and needs triageOpened without agent diagnostics and needs triage

   on Aug 20, 2026
2. jiridanek commented on Aug 21, 2026

   

   jiridanek

   on Aug 21, 2026

   Last edited by jiridanek

   More actions

   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.
3. elezar commented on Aug 24, 2026

   

   elezar

   on Aug 24, 2026

   Member

   More actions

   📋 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.
4. elezar

   added

   state:validated

   area:buildRelated to CI/CD and buildsRelated to CI/CD and builds

   topic:testing

   test:e2eRequires end-to-end coverageRequires end-to-end coverage

   os:linuxIssue affects Linux hostsIssue affects Linux hosts

   state:acceptedA maintainer decided OpenShell should pursue this issueA maintainer decided OpenShell should pursue this issue

   and removed

   state:triage-neededOpened without agent diagnostics and needs triageOpened without agent diagnostics and needs triage

   state:validated

   on Aug 24, 2026
5. elezar

   marked ci: pasta AppArmor denial check is diagnostic-only, allowing silent regression of #2844 #2906 as a duplicate of this issue on Aug 25, 2026
6. elezar

   closed this as completedin #2900on Aug 25, 2026