compat: skip AppArmor profile assignment when service runs inside a container

[Mohataseem89]

Problem

On kernel 6.17, starting a container via the Docker-compat API
(docker compose / docker CLI pointed at the podman socket) from
inside a systemd/Quadlet-launched container fails with:

The container is created but stuck in Created state. Native
podman run on the host works fine. podman --remote also works.
Only the compat API path from inside a confined systemd/Quadlet
container fails.

Root cause: when no apparmor= SecurityOpt is sent by the Docker
client, the compat path falls through to the containers-default-*
profile from containers.conf. On kernel 6.17, crun's write to
/proc/thread-self/attr/apparmor/exec is blocked by the outer
container's AppArmor policy, which does not permit change_profile.

Fix

When /run/.containerenv is present (podman sets this inside every
container) and the client sent no explicit apparmor= SecurityOpt,
inject apparmor=unconfined so crun skips the profile-assignment
write entirely.

Users who need a specific AppArmor profile can still pass
--security-opt apparmor=<profile> explicitly.

The proper upstream fix (adding change_profile -> **, to the
containers-default profile template) is in containers/common:
containers/common#2548
containers/common/pull/2548

References

• Fixes: Docker-compat API container start fails AppArmor assignment (crun: unable to assign security attribute) on kernel 6.17 while native podman works #28992
• Downstream report: Periphery 'docker compose' deploy strands containers in 'Created' on kernel 6.17 (crun AppArmor: unable to assign security attribute) moghtech/komodo#1488
• containers/common fix: apparmor: allow change_profile for nested container runtimes containers/common#2548
  apparmor: allow change_profile for nested container runtimes containers/common#2548
  apparmor: allow change_profile for nested container runtimes container-libs#942

[Luap99]

That is just not a valid option from a security POV, we cannot just ignore existing profiles, either the profile works or it does not. If this needs additional policy change to work fine, but we cannot just say unconfined and ignore this without the caller knowing that they are not protected by it.

This also does not explain at all why this would only be specific to the compat API. There is not special handing for apparmor with the API here

also please note https://github.com/podman-container-tools/podman/blob/main/LLM_POLICY.md

And at minimum details also must be part of the commit message not just a PR description.
And it would help if you follow our PR template instead of this AI format.

[Mohataseem89]

Closing this @Luap99 is right that silently setting unconfined is a bad security tradeoff.ig the podman-container-tools/container-libs/pull/942 fix (adding change_profile to the profile template) is the right approach. Will focus there instead