Docker-compat API container start fails AppArmor assignment (crun: unable to assign security attribute) on kernel 6.17 while native podman works

[jflammia]

Issue Description

On kernel 6.17 / podman 5.4.2 / crun 1.21, starting a container via the Docker-compatible API (docker compose / docker CLI pointed at the podman socket), when the client runs inside a systemd/Quadlet-launched container, fails AppArmor profile assignment:

crun: `/proc/thread-self/attr/apparmor/exec`: OCI runtime error: unable to assign security attribute

The container is created but never started (stuck Created). Native podman does the identical operation fine.

This is the same attr/apparmor/exec write addressed by crun #1350 / #1352 — and crun 1.21 does use the LSM-specific path — but the write still fails on this kernel.

Confirmed (same host, same podman socket)

Path	Result
podman run (host CLI)	✅ works
podman --remote run via the socket, any apparmor profile (default / unconfined / exact loaded containers-default-0.62.2)	✅ works
docker run / docker compose via Docker-compat API from a Quadlet/systemd-launched container	❌ crun AppArmor error

Uncertain / not fully isolated

A nested docker run from a throwaway podman run <same-image> container succeeds — only the systemd/Quadlet-launched container (with --cgroups=split --sdnotify=conmon) running the Docker-compat client fails. So the trigger appears to be the combination of (Docker-compat API path) × (systemd/Quadlet launch context) on kernel 6.17, not the Docker-compat path alone.

Environment

• podman 5.4.2, crun 1.21, containers-common 0.62.2 (AppArmor containers-default-0.62.2)
• kernel 6.17.0-35-generic (Ubuntu); LSM order lockdown,capability,landlock,yama,apparmor,ima,evm (apparmor is the only LSM claiming attr/exec, so the crun docs: use "containers-" prefix and add containers-mounts.conf #1350 LSM-ordering workaround does not apply)
• rootful podman socket; the failing client runs in a container with the socket bind-mounted

Ruled out

periphery/container restart; apparmor=unconfined (on the outer container and on the requested profile); /proc rw vs :ro; host containers.conf apparmor_profile=unconfined; explicit loaded profile via Docker-compat; crun/podman upgrades (Ubuntu repo max). LSM reorder N/A.

Questions

1. Is the AppArmor attr/apparmor/exec write expected to fail for the Docker-compat create path on kernel 6.17 where native podman succeeds?
2. Is there a known kernel-6.17 AppArmor regression here, or a podman/crun-side fix?

Downstream context (reliable reproduction via Komodo Periphery): moghtech/komodo#1488.

[Luap99]

Note https://github.com/podman-container-tools/podman/blob/main/LLM_POLICY.md, and please follow our normal bug template.

As general rule we only support the latest upstream release so please test with the last code.
And we would need a minimal reproducer, i.e. exact steps, the linked issue does not contain any more info either

[github-actions]

A reviewer has determined we need more information to understand the reported issue. A comment on what is missing should be provided. Be certain you:

• provide an exact reproducer where possible
• verify you have provided all relevant information - minimum is podman info
• answer any follow up questions

If no response to the needs-info is provided in 30 days, this issue may be closed by our stale bot.

For more information on reporting issues on this repository, consult our issue guide.