ci: pasta AppArmor denial check is diagnostic-only, allowing silent regression of #2844

[politerealism]

User Story

As an OpenShell maintainer, I want the rootless Podman E2E job to fail loudly if the pasta/Podman SIGTERM AppArmor denial ever reoccurs, so that a future regression of #2844 is caught by CI instead of silently reintroducing flaky tests.

Problem Statement

PR #2900 fixed #2844 by adding a signal (receive) peer=podman, rule to the pasta AppArmor profile on ubuntu-26.04 E2E runners, and verifies the fix by checking that the rule text was inserted into the profile file and that apparmor_parser reloaded it successfully. It does not verify at runtime that no AppArmor denial actually occurs during the E2E run.

The workflow's existing "Print AppArmor denials" step (.github/workflows/e2e-test.yml) is diagnostic-only:

- name: Print AppArmor denials
 if: always()
 run: sudo dmesg | grep -E 'apparmor=.*DENIED|profile="unprivileged_userns"' | tail -100 || true

The || true means this step never fails the job, regardless of what it finds.

Impact / Why This Matters

If a future Ubuntu runner image update, passt package bump, or AppArmor abstraction restructuring changes runtime enforcement behavior without breaking the static text match PR #2900 checks for, the exact flakiness from #2844 (15s SIGKILL fallback on every rootless container stop, non-deterministic test failures depending on timeout timing) could silently reoccur with CI staying green. Nothing currently turns a matching profile="pasta" ... signal=term denial in dmesg into an actual job failure.

Current workaround: none — this is a latent gap, not an active failure. The only way to notice a regression today would be a human manually reading the "Print AppArmor denials" step output after test flakiness reappears — the same discovery path that produced #2844 in the first place.

Acceptance Criteria

• The rootless Podman E2E job fails if dmesg contains a line matching profile="pasta" combined with signal=term after the test run
• A deliberately-reverted pasta AppArmor rule causes the job to fail with a clear error message (manual validation)
• (Nice-to-have) The rootless E2E job is validated with repeated runs and/or a container-stop time bound, rather than relying on a single passing run, per the suggestion made during triage of ci: AppArmor profile blocks pasta from receiving SIGTERM on ubuntu-26.04 runners, failing rootless E2E #2844

Reproduction Steps

1. Revert the signal (receive) peer=podman, rule added in fix(ci): allow pasta to receive Podman stop signals #2900, or otherwise cause pasta to deny Podman's SIGTERM again
2. Run the E2E (rust-podman-rootless, ubuntu-26.04) job
3. Observe: dmesg contains the denial, but the job's "Print AppArmor denials" step exits 0 regardless, and the job can still pass if no individual test happens to cross its timeout

Environment

• Runner: ubuntu-26.04 (NVIDIA managed runners)
• Podman: 5.7.0+ds2-3build1 (rootless mode)
• Related: ci: AppArmor profile blocks pasta from receiving SIGTERM on ubuntu-26.04 runners, failing rootless E2E #2844, fix(ci): allow pasta to receive Podman stop signals #2900

[elezar]

📋 triage-agent

Triage Assessment

Classification: duplicate

This report identified a real regression-detection gap, but it is now covered by accepted issue #2844. The current implementation PR #2900 adds the requested Fail on pasta SIGTERM AppArmor denial step: it detects the specific pasta/Podman SIGTERM denial in dmesg, emits a clear error, and exits nonzero. Its updated rootless Podman E2E job passed with that guard.

#2844 remains the canonical issue for the AppArmor/pasta failure and its regression coverage. #2900 is still open, so this is not a fixed-in-release disposition.